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".
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.
Don't panic in Vec::shrink_to_fit
We can help the compiler see that `Vec::shrink_to_fit` will never reach the panic case in `RawVec::shrink_to_fit`, just by guarding the call only for cases where the capacity is strictly greater. A capacity less than the length is only possible through an unsafe call to `set_len`, which would break the `Vec` invariants, so `shrink_to_fit` can just ignore that.
This removes the panicking code from the examples in both #71861 and #75636.
Cargo update (almost) all the things!
This runs `cargo update` on our dependency tree, bumping numerous crates. See details in the first commit of this PR.
Several updates were held back intentionally; version_check in particular landed a change in behavior in 0.9.2 (arguably a bug fix, but still will be split into a separate PR).
Promote missing_fragment_specifier to hard error
It has been deny_by_default since 2017 (and warned for some time
before that), so it seems reasonable to promote it.
The specific technical motivation to do this now is to remove a field
from `ParseSess` -- it is a global state, and global state makes
extracting libraries annoying.
Closes#40107
cmake-rs@8141f0e changed the logic for handling asm compiler flags.
This change was pulled in with the cmake 0.1.42 -> 0.1.44 update.
This introduced two new flags to the LLVM build, breaking it:
"-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64"
"-DCMAKE_ASM_COMPILER=/usr/bin/cc"
This patch should resolve the breakage by handling it in bootstrap.
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#75599
Don't use `dep_graph.with_ignore` when encoding fn param names
The call to `with_ignore` was added years ago, and should no longer be
necessary with the modern incremental query infrastructure.
I also removed a related FIXME comment for issue #38501, which was
closed months ago.
treeify depends on an outdated version of clap, which will fail to compile
when we promote missing_fragment_specifier future compat lint to
error (ie, old clap contains code that shouldn't have compiled in the
first place).
Additionally, this crate seem tiny relative to other crates we are
testing here, so it seems like it doesn't provide that much additional
confidence.
The same happens with tokei project, but it is an actively maintained
one, so we can just upgrade it to a version from 2018, where clap was
upgraded.
Suppress verbose MIR comments for trivial types
Addresses #74508
This is my first contribution to the Rust project! Please let me know if anything needs revising, I'm happy to make changes.
It has been deny_by_default since 2017 (and warned for some time
before that), so it seems reasonable to promote it.
The specific technical motivation to do this now is to remove a field
from `ParseSess` -- it is a global state, and global state makes
extracting libraries annoying.
Closes#40107
