Implement `last` for `EscapeUnicode`
The implementation is quite trivial as the last character is always `'{'`.
As a side-effect it also improves the implementation of `last` for `EscapeUnicode`.
Part of #24214, split from #31049.
Maybe this (and the other changes that I will split from #31049) should wait for a test like `ed_iterator_specializations` to be added. Would it be sufficient to do the same for each possible escape length?
Fix fast path of float parsing on x87
The fast path of the float parser relies on the rounding to happen
exactly and directly to the correct number of bits. On x87, instead,
double rounding would occour as the FPU stack defaults to 80 bits of
precision.
This can be fixed by setting the precision of the FPU stack before
performing the int to float conversion. This can be achieved by
changing the value of the x87 control word. This is a somewhat common
operation that is in fact performed whenever a float needs to be
truncated to an integer, but it is undesirable to add its overhead for
code that does not rely on x87 for computations (i.e. on non-x86
architectures, or x86 architectures which perform FPU computations on
using SSE).
Fixes `num::dec2flt::fast_path_correct` (on x87).
Remove irrelevant information (and instead provide pointer to
reference documentation), replace ASCII-art table with the
corresponding MarkDown one, and minor fixes.
Make AtomicBool the same size as bool
Reopening #32365
This allows `AtomicBool` to be transmuted to a `bool`, which makes it more consistent with the other atomic types. Note that this now guarantees that the atomic type will always contain a valid `bool` value, which wasn't the case before (due to `fetch_nand`).
r? @alexcrichton
Explain the meaning of the fields of the control word and provide more
details about how the relevant one (Precision Control) is updated in
the fast path.
The fast path of the float parser relies on the rounding to happen
exactly and directly to the correct number of bits. On x87, instead,
double rounding would occour as the FPU stack defaults to 80 bits of
precision.
This can be fixed by setting the precision of the FPU stack before
performing the int to float conversion. This can be achieved by
changing the value of the x87 control word. This is a somewhat common
operation that is in fact performed whenever a float needs to be
truncated to an integer, but it is undesirable to add its overhead for
code that does not rely on x87 for computations (i.e. on non-x86
architectures, or x86 architectures which perform FPU computations on
using SSE).
Fixes `num::dec2flt::fast_path_correct` (on x87).
rustbuild: Add support for crate tests + doctests
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
This commit adds support to rustbuild to run crate unit tests (those defined by
`#[test]`) as well as documentation tests. All tests are powered by `cargo test`
under the hood.
Each step requires the `libtest` library is built for that corresponding stage.
Ideally the `test` crate would be a dev-dependency, but for now it's just easier
to ensure that we sequence everything in the right order.
Currently no filtering is implemented, so there's not actually a method of
testing *only* libstd or *only* libcore, but rather entire swaths of crates are
tested all at once.
A few points of note here are:
* The `coretest` and `collectionstest` crates are just listed as `[[test]]`
entires for `cargo test` to naturally pick up. This mean that `cargo test -p
core` actually runs all the tests for libcore.
* Libraries that aren't tested all mention `test = false` in their `Cargo.toml`
* Crates aren't currently allowed to have dev-dependencies due to
rust-lang/cargo#860, but we can likely alleviate this restriction once
workspaces are implemented.
cc #31590
Add rustc_on_unimplemented for Index implementation on slice
Reopening of #31071.
It also extends the possibility of `#[rustc_on_unimplemented]` by providing a small type filter in order to find the ones which corresponds the most.
r? @pnkfelix
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.
