implement RFC 1521
Adds documentation to Clone, specifying that Copy types should have a trivial Clone impl.
Fixes#33416.
I tried to use "should" and "must" as defined [here](https://tools.ietf.org/html/rfc2119).
cc @ubsan
Short-cut `T: Sized` trait selection for ADTs
Basically avoids all nested obligations when checking whether an ADT is sized - this speeds up typeck by ~15%
The refactoring fixed#32963, but I also want to make `Copy` not object-safe (will commit that soon).
Fixes#33201
r? @nikomatsakis
This is safe since the borrow checker ensures that we have the only
mutable reference to the struct, thus we can safely borrow its interior.
Tracking issue is #33444.
This requirement appears to be missing from RFC1214, but is clearly
necessary for translation. The last field of a tuple/enum remains in
a state of limbo, compiling but causing an ICE when it is used - we
should eventually fix that somehow.
this is a [breaking-change] - a soundness fix - and requires a
crater run.
docs: Changed docs for `size_of` to describe size as a stride offset
Current documentation for `std::mem::size_of` is ambiguous, and the documentation for `std::intrinsics::size_of` incorrectly defines size.
This fix re-defines size as the offset in bytes between successive instances of a type, as described in LLVM's [getTypeAllocSize](http://llvm.org/docs/doxygen/html/classllvm_1_1DataLayout.html#a1d6fcc02e91ba24510aba42660c90e29).
Fixes: #33266
Current description of `std::mem::size_of` is ambiguous, and the
`std::intrinsics::size_of` description incorrectly defines size
as the number of bytes necessary to exactly overwrite a value,
not including the padding between elements necessary in a vector
or structure.
special-case #[derive(Copy, Clone)] with a shallow clone
If a type is Copy then its Clone implementation can be a no-op. Currently `#[derive(Clone)]` generates a deep clone anyway. This can lead to lots of code bloat.
This PR detects the case where Copy and Clone are both being derived (the general case of "is this type Copy" can't be determined by a syntax extension) and generates the shallow Clone impl. Right now this can only be done if there are no type parameters (see https://github.com/rust-lang/rust/issues/31085#issuecomment-178988663), but this restriction can be removed after specialization.
Fixes#31085.
Changes #[derive(Copy, Clone)] to use a faster impl of Clone when
both derives are present, and there are no generics in the type.
The faster impl is simply returning *self (which works because the
type is also Copy). See the comments in libsyntax_ext/deriving/clone.rs
for more details.
There are a few types which are Copy but not Clone, in violation
of the definition of Copy. These include large arrays and tuples. The
very existence of these types is arguably a bug, but in order for this
optimization not to change the applicability of #[derive(Copy, Clone)],
the faster Clone impl also injects calls to a new function,
core::clone::assert_receiver_is_clone, to verify that all members are
actually Clone.
This is not a breaking change, because pursuant to RFC 1521, any type
that implements Copy should not do any observable work in its Clone
impl.
The example uses integers for the value being iterated over, but the indices
added by `enumerate` are also integers, so I always end up double taking and
thinking harder than I should when parsing the documentation. I also always
forget which order the index and value are in the tuple so I frequently hit this
stumbling block. This commit changes the documentation to iterate over
characters so that it is immediately obvious which part of the tuple is the
index and which is the value.
Split core::iter module implementation into parts
Split core::iter module implementation into parts
split iter.rs into a directory of (implementation private) modules.
+ mod (adaptor structs whose private fields need to be available both for them and Iterator
+ iterator (Iterator trait)
+ traits (FromIterator, etc; all traits but Iterator itself)
+ range (range related)
+ sources (Repeat, Once, Empty)
mk: Bootstrap from stable instead of snapshots
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.
A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.
One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:
* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
(enabled as a result of #32731) and exported by the build system. This enables
nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
doesn't change, so we're guaranteed that we'll continue compiling as we start
from a known fixed source.
The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:
1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.
Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.
Closes#29555Closes#29557
Improve computation of offset in `EscapeUnicode`
Unify the computation of `offset` and use `leading_zeros` instead of manually scanning the bits.
This PR removes some duplicated code and makes it a little simpler .
The computation of `offset` is also faster, but it is unlikely to have an impact on actual code.
(split from #31049)
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.
A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.
One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:
* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
(enabled as a result of #32731) and exported by the build system. This enables
nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
doesn't change, so we're guaranteed that we'll continue compiling as we start
from a known fixed source.
The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:
1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.
Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.
Closes#29555Closes#29557
split iter.rs into a directory of (implementation private) modules.
+ mod Adaptor structs
- Private fields need to be available both for them and Iterator
+ iterator (Iterator trait)
+ traits (FromIterator, traits but Iterator itself)
+ range (range related)
+ sources (Repeat, Once, Empty)
collections: Add slice::binary_search_by_key
This method adds to the family of `_by_key` methods, and is the
counterpart of `slice::sort_by_key`. It was mentioned on #30423 but
was not implemented at that time.
Refs #30423
