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 10 pull requests #75683

Closed
wants to merge 43 commits into from
Closed

Conversation

tmandry
Copy link
Member

@tmandry tmandry commented Aug 18, 2020

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>
* Impl IntoInner rather than AsInner for Ipv4Addr
* Add some comments
* Add test to show endiannes of Ipv4Addr display
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>
GuillaumeGomez and others added 13 commits August 18, 2020 13:31
This adds another `derive` for a `Copy`able struct, so that we are
consistent with `derive` annotations.
…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".
…crum

Minor changes to Ipv4Addr

Minor changes to Ipv4Addr

* Impl IntoInner rather than AsInner for Ipv4Addr
* Add some comments
* Add test to show endiannes of Ipv4Addr display
Capture output from threads spawned in tests

Fixes rust-lang#42474.

r? @dtolnay since you expressed interest in this, but feel free to redirect if you aren't the right person anymore.
…rk-Simulacrum

BTreeMap: check some invariants in unit tests
…-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
…aumeGomez

Fix intra-doc links for inherent impls that are both lang items and not the default impl

I found in rust-lang#75464 (comment) that `str::to_uppercase()` doesn't resolve while `str::trim()` does. The only real difference is that `to_uppercase` is defined in `alloc`, while trim is defined in `core`. It turns out that rustdoc was ignoring `lang_items.str_alloc_impl()` - it saw them in `collect_trait_impls`, but not for intra-doc links.

This uses the same `impls` for all parts of rustdoc, so that there can be no more inconsistency. It does have the slight downside that the matches are no longer exhaustive but it will be very clear if a new lang item is missed because it will panic when you try to document it (and if you don't document it, does rustdoc really need to know about it?).

~~This needs a test case (probably just `str::to_uppercase`).~~ Added.

This is best reviewed commit-by-commit.

r? @GuillaumeGomez
@tmandry
Copy link
Member Author

tmandry commented Aug 18, 2020

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

@bors
Copy link
Contributor

bors commented Aug 18, 2020

📌 Commit 2a5b4b2 has been approved by tmandry

@rustbot rustbot added the rollup A PR which is a rollup label Aug 18, 2020
@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 18, 2020
@bors
Copy link
Contributor

bors commented Aug 18, 2020

⌛ Testing commit 2a5b4b2 with merge 9696f43b91a14f6b046dc9ee0aa925c0169dbda8...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-netbsd of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[RUSTC-TIMING] addr2line test:false 0.406
[RUSTC-TIMING] core test:false 21.702
[RUSTC-TIMING] gimli test:false 5.157
[RUSTC-TIMING] object test:false 10.395
error: borrow of packed field is unsafe and requires unsafe function or block (error E0133)
    |
    |
913 |         self.inner.s_addr.hash(s)
    |
    |
    = note: `-D safe-packed-borrows` implied by `-D warnings`
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #46043 <https://github.com/rust-lang/rust/issues/46043>
    = note: fields of packed structs might be misaligned: dereferencing a misaligned pointer or even just creating a misaligned reference is undefined behavior
error: aborting due to previous error

[RUSTC-TIMING] std test:false 3.351
error: could not compile `std`.
---
== clock drift check ==
  local time: Tue Aug 18 23:33:21 UTC 2020
  network time: Tue, 18 Aug 2020 23:33:21 GMT
== end clock drift check ==
##[error]Process completed with exit code 1.
Terminate orphan process: pid (2808) (node)
Terminate orphan process: pid (2836) (python)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @rust-lang/infra. (Feature Requests)

@bors
Copy link
Contributor

bors commented Aug 18, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 18, 2020
@tmandry tmandry closed this Aug 18, 2020
@tmandry tmandry deleted the rollup-mw76h3y branch August 18, 2020 23:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.