Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 9 pull requests #75692

Merged
merged 35 commits into from
Aug 19, 2020
Merged

Rollup of 9 pull requests #75692

merged 35 commits into from
Aug 19, 2020

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost

Havvy and others added 30 commits August 1, 2020 22:56
In the current documentation about the `Copy` marker trait, there is a section
about "additional implementors", which list additional implementors of the `Copy` trait.
The fact that shared references are also `Copy` is mixed with another point,
which makes it hard to recognize and make it seem not as important.

This clarifies the fact that shared references are also `Copy`, by mentioning it as a
separate item in the list of "additional implementors".
In the current documentation about the `Copy` marker trait, there is a section
with examples of structs that can implement `Copy`. Currently there is no example for
showing that shared references (`&T`) are also `Copy`.
It is worth to have a dedicated example for `&T` being `Copy`, because shared
references are an integral part of the language and it being `Copy` is not as
intuitive as other types that share this behaviour like `i32` or `bool`.

The example picks up on the previous non-`Copy` struct and shows that
structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type.
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Co-authored-by: Poliorcetics <poliorcetics@users.noreply.github.com>
Code blocks in doc comments are compiled and run, so we show `Copy` works in this example.

Co-authored-by: Poliorcetics <poliorcetics@users.noreply.github.com>
Adds a seen set to structurally_same_type to avoid recursing
indefinitely when a reference or pointer member introduces a cycle in
the visited types.
That cache is unlikely to be particularly useful within a single
invocation of structurally_same_type, especially compared to memoizing
results across _all_ invocations of that function.
Co-authored-by: Bastian Kauschke <bastian_kauschke@hotmail.de>
This adds another `derive` for a `Copy`able struct, so that we are
consistent with `derive` annotations.
…xpressions

Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.

Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.

Fixes rust-lang#75599
…bnik

See also X-Link mem::{swap, take, replace}

Since it's easy to end up at one of these functions when you really wanted the other one, cross link them with descriptions of why you'd want to use them.
docs(marker/copy): provide example for `&T` being `Copy`

### Edited 2020-08-16 (most recent)
In the current documentation about the `Copy` marker trait, there is a section
with examples of structs that can implement `Copy`. Currently there is no example for
showing that shared references (`&T`) are also `Copy`.
It is worth to have a dedicated example for `&T` being `Copy`, because shared
references are an integral part of the language and it being `Copy` is not as
intuitive as other types that share this behaviour like `i32` or `bool`.

The example picks up on the previous non-`Copy` struct and shows that
structs can be `Copy`, even when they hold a shared reference to a non-`Copy` type.

-----------------------------------------
### Edited 2020-08-02, 3:28 p.m.
I've just realized that it says "in addition to the **implementors listed below**", which makes this PR kind of "wrong", because `&T` is indeed in the "implementors listed below".
Maybe we can instead show an example with `&T` in the [When can my type be Copy](https://doc.rust-lang.org/std/marker/trait.Copy.html#when-can-my-type-be-copy) section.

What I really want to achieve is that it becomes more obvious that `&T` is also `Copy`, because, I think, it is very valuable to know and it wasn't obvious for me, until I read something about it in a forum post.

What do you think? I would create another PR for that.
**Please feel free to close this PR.**

-----------------------------------
### Original post
In the current documentation about the `Copy` marker trait, there is a section
about "additional implementors", which list additional implementors of the `Copy` trait.
The fact that shared references are also `Copy` is mixed with another point,
which makes it hard to recognize and make it seem not as important.

This clarifies the fact that shared references are also `Copy`, by mentioning it as a
separate item in the list of "additional implementors".
…-75412, r=Dylan-DPC

Fix documentation error

This should fix rust-lang#75412. Just a quick >= to > sign replacement.
…erflow, r=lcnr

Fix clashing_extern_declarations stack overflow for recursive types.

Fixes rust-lang#75512.

Adds a seen set to `structurally_same_type` to avoid recursing indefinitely for types which contain values of the same type through a pointer or reference.
…r=jyn514

Move to intra doc links for keyword documentation

Helps with rust-lang#75080.

@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc
Resolve true and false as booleans

Successor to rust-lang#75101.

r? @Manishearth
cc @rust-lang/rustdoc
Don't emit "is not a logical operator" error outside of associative expressions

Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.

Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.

Fixes rust-lang#75599

---

First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)
Switch to intra-doc links in /src/sys/unix/ext/*.rs

Partial fix for rust-lang#75080

@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc

r? @jyn514

These two links are not resolving to either `crate::fs::File...` or `fs::File...`
```
# unix/ext/fs.rs
   27:    /// [`File::read`]: ../../../../std/fs/struct.File.html#method.read

  130:   /// [`File::write`]: ../../../../std/fs/struct.File.html#method.write
```
@JohnTitor
Copy link
Member Author

@bors r+ p=5 rollup=never
@rustbot modify labels: +rollup

@rustbot rustbot added the rollup A PR which is a rollup label Aug 19, 2020
@bors
Copy link
Contributor

bors commented Aug 19, 2020

📌 Commit 07ea340 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 19, 2020
@bors
Copy link
Contributor

bors commented Aug 19, 2020

⌛ Testing commit 07ea340 with merge 5b04bbf...

@bors
Copy link
Contributor

bors commented Aug 19, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: JohnTitor
Pushing 5b04bbf to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 19, 2020
@bors bors merged commit 5b04bbf into rust-lang:master Aug 19, 2020
@JohnTitor JohnTitor deleted the rollup-8gr04ah branch August 19, 2020 11:21
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.