Improve docs for Waker::noop and LocalWaker::noop
* Add a warning about a likely misuse. (See my commit message for longer rationale.)
* Apply some probably-accidentally-omitted changes to `LocalWaker`'s docs
* Add a comment about the clone-and-hack of the docs
I have used [semantic linefeeds](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) for the docs formatting.
Hash Ipv*Addr as an integer
The `Ipv4Addr` and `Ipv6Addr` structs always have a fixed size, but directly derive `Hash`. This causes them to call the bytestring hasher implementation, which adds extra work for most hashers. This PR converts the internal representation to a fixed-width integer before passing to the hasher to prevent this.
derive(SmartPointer): register helper attributes
Fix#128888
This PR enables built-in macros to register helper attributes, if any, to support correct name resolution in the correct lexical scope under the macros.
Also, `#[pointee]` is moved into the scope under `derive(SmartPointer)`.
cc `@Darksonn` `@davidtwco`
CommandExt::before_exec: deprecate safety in edition 2024
Similar to `set_var`, we had to find out after 1.0 was released that `before_exec` should have been unsafe. We partially rectified this by deprecating that function a long time ago, but since https://github.com/rust-lang/rust/pull/124636 we have the ability to also deprecate the safety of the old function and make it a *hard error* to call the old function outside `unsafe` in the next edition. So just in case anyone still uses the old function, let's ensure this can't be ignored when moving code to the new edition.
Cc `@rust-lang/libs-api`
Tracking:
- https://github.com/rust-lang/rust/issues/124866
Explicitly specify type parameter on FromResidual for Option and ControlFlow.
~~Remove type parameter default `R = <Self as Try>::Residual` from `FromResidual`~~ _Specify default type parameter on `FromResidual` impls in the stdlib_ to work around https://github.com/rust-lang/rust/issues/99940 / https://github.com/rust-lang/rust/issues/87350 ~~as mentioned in https://github.com/rust-lang/rust/issues/84277#issuecomment-1773259264~~.
This does not completely fix the issue, but works around it for `Option` and `ControlFlow` specifically (`Result` does not have the issue since it already did not use the default parameter of `FromResidual`).
~~(Does this need an ACP or similar?)~~ ~~This probably needs at least an FCP since it changes the API described in [the RFC](https://github.com/rust-lang/rfcs/pull/3058). Not sure if T-lang, T-libs-api, T-libs, or some combination (The tracking issue is tagged T-lang, T-libs-api).~~ This probably doesn't need T-lang input, since it is not changing the API of `FromResidual` from the RFC? Maybe needs T-libs-api FCP?
Rollup of 7 pull requests
Successful merges:
- #122884 (Optimize integer `pow` by removing the exit branch)
- #127857 (Allow to customize `// TODO:` comment for deprecated safe autofix)
- #129034 (Add `#[must_use]` attribute to `Coroutine` trait)
- #129049 (compiletest: Don't panic on unknown JSON-like output lines)
- #129050 (Emit a warning instead of an error if `--generate-link-to-definition` is used with other output formats than HTML)
- #129056 (Fix one usage of target triple in bootstrap)
- #129058 (Add mw back to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Add windows-targets crate to std's sysroot
With this PR, when backtrace is used as a crate from crates.io it will (once updated) use the real [windows-targets](https://crates.io/crates/windows-targets) crate. But when used from std it'll use std's replacement version.
This allows sharing our customized `windows_tagets::link!` macro between std proper and the backtrace crate when used as part of std, ensuring a consistent linking story. This will be especially important once we move to using [`raw-dylib`](https://doc.rust-lang.org/reference/items/external-blocks.html#dylib-versus-raw-dylib) by default.
Add `#[must_use]` attribute to `Coroutine` trait
[Coroutines tracking issue](https://github.com/rust-lang/rust/issues/43122)
Like closures (`FnOnce`, `AsyncFn`, etc.), coroutines are lazy and do nothing unless called (resumed). Closure traits like `FnOnce` have `#[must_use = "closures are lazy and do nothing unless called"]` to catch likely bugs for users of APIs that produce them. This PR adds such a `#[must_use]` attribute to `trait Coroutine`.
Allow to customize `// TODO:` comment for deprecated safe autofix
Relevant for the deprecation of `CommandExt::before_exit` in #125970.
Tracking:
- #124866
Optimize integer `pow` by removing the exit branch
The branch at the end of the `pow` implementations is redundant with multiplication code already present in the loop. By rotating the exit check, this branch can be largely removed, improving code size and reducing instruction cache misses.
Testing on my machine (`x86_64`, 11th Gen Intel Core i5-1135G7 @ 2.40GHz), the `num::int_pow` benchmarks improve by some 40% for the unchecked operations and show some slight improvement for the checked operations as well.
Remove unused lifetime parameter from spawn_unchecked
Amanieu caught this when reviewing the stabilization proposal in https://github.com/rust-lang/rust/issues/55132.
The `'a` lifetime here is useless. The signature is asking the caller of `spawn_unchecked` to "give me any lifetime that is shorter than your F's and T's lifetime", which they can always to with no effect, because arbitrarily short lifetimes exist.
std: refactor UNIX random data generation
This PR makes a number of changes to the UNIX randomness implementation:
* Use `io::Error` for centralized error handling
* Move the file-fallback logic out of the `getrandom`-specific module
* Stop redefining the syscalls on macOS and DragonFly, they have appeared in `libc`
* Add a `OnceLock` to cache the random device file descriptor
miri: make vtable addresses not globally unique
Miri currently gives vtables a unique global address. That's not actually matching reality though. So this PR enables Miri to generate different addresses for the same type-trait pair.
To avoid generating an unbounded number of `AllocId` (and consuming unbounded amounts of memory), we use the "salt" technique that we also already use for giving constants non-unique addresses: the cache is keyed on a "salt" value n top of the actually relevant key, and Miri picks a random salt (currently in the range `0..16`) each time it needs to choose an `AllocId` for one of these globals -- that means we'll get up to 16 different addresses for each vtable. The salt scheme is integrated into the global allocation deduplication logic in `tcx`, and also used for functions and string literals. (So this also fixes the problem that casting the same function to a fn ptr over and over will consume unbounded memory.)
r? `@saethlin`
Fixes https://github.com/rust-lang/miri/issues/3737
std: do not overwrite style in `get_backtrace_style`
If another thread calls `set_backtrace_style` while a `get_backtrace_style` is reading the environment variables, `get_backtrace_style` will overwrite the value. Use an atomic CAS to avoid this.
nontemporal_store: make sure that the intrinsic is truly just a hint
The `!nontemporal` flag for stores in LLVM *sounds* like it is just a hint, but actually, it is not -- at least on x86, non-temporal stores need very special treatment by the programmer or else the Rust memory model breaks down. LLVM still treats these stores as-if they were normal stores for optimizations, which is [highly dubious](https://github.com/llvm/llvm-project/issues/64521). Let's avoid all that dubiousness by making our own non-temporal stores be truly just a hint, which is possible on some targets (e.g. ARM). On all other targets, non-temporal stores become regular stores.
~~Blocked on https://github.com/rust-lang/stdarch/pull/1541 propagating to the rustc repo, to make sure the `_mm_stream` intrinsics are unaffected by this change.~~
Fixes https://github.com/rust-lang/rust/issues/114582
Cc `@Amanieu` `@workingjubilee`
If another thread calls `set_backtrace_style` while a `get_backtrace_style` is reading the environment variables, `get_backtrace_style` will overwrite the value. Use an atomic CAS to avoid this.
fix: #128855 Ensure `Guard`'s `drop` method is removed at `opt-level=s` for `…
fix: #128855
…Copy` types
Added `#[inline]` to the `drop` method in the `Guard` implementation to ensure that the method is removed by the compiler at optimization level `opt-level=s` for `Copy` types. This change aims to align the method's behavior with optimization expectations and ensure it does not affect performance.
r? `@scottmcm`
Apply "polymorphization at home" to RawVec
The idea here is to move all the logic in RawVec into functions with explicit size and alignment parameters. This should eliminate all the fussing about how tweaking RawVec code produces large swings in compile times.
This uncovered https://github.com/rust-lang/rust-clippy/issues/12979, so I've modified the relevant test in a way that tries to preserve the spirit of the test without tripping the ICE.
core: optimise Debug impl for ascii::Char
Rather than writing character at a time, optimise Debug implementation
for core::ascii::Char such that it writes the entire representation
with a single write_str call.
With that, add tests for Display and Debug.
Issue: https://github.com/rust-lang/rust/issues/110998
Improve `Ord` violation help
Recent experience in #128083 showed that the panic message when an Ord violation is detected by the new sort implementations can be confusing. So this PR aims to improve it, together with minor bug fixes in the doc comments for sort*, sort_unstable* and select_nth_unstable*.
Is it possible to get these changes into the 1.81 release? It doesn't change behavior and would greatly help when users encounter this panic for the first time, which they may after upgrading to 1.81.
Tagging `@orlp`
Rather than writing character at a time, optimise Debug implementation
for core::ascii::Char such that it writes the entire representation as
with a single write_str call.
With that, add tests for Display and Debug implementations.
The documentation incorrectly stated that std::env::var could return
an error for variable names containing '=' or the NUL byte. Copy the
correct documentation from var_os.
var_os was fixed in Commit 8a7a665, Pull Request #109894, which
closed Issue #109893.
This documentation was incorrectly added in commit f2c0f292, which
replaced a panic in var_os by returning None, but documented the
change as "May error if ...".
Reference the specific error values and link to them.
VxWorks code refactored
1. Extern TaskNameSet as minimum supported version of os is VxWorks 7 which would have taskNameSet
2. Vx_TASK_NAME_LEN is 31 on VxWorks7, defined variable res.
3. Add unsafe blocks on Non::Zero usage in available_parallelism()
4. Update vxworks docs.
r? `@tgross35`
cc `@devnexen`
Added `#[inline]` to the `drop` method in the `Guard` implementation to ensure that the method is removed by the compiler at optimization level `opt-level=s` for `Copy` types. This change aims to align the method's behavior with optimization expectations and ensure it does not affect performance.
rwlock: disable 'frob' test in Miri on macOS
Due to https://github.com/rust-lang/rust/issues/121950, Miri will sometimes complain about this test on macOS. Better disable the test, as otherwise it can fail for unrelated PRs.
r? ``@joboet``
Mark `{f32,f64}::{next_up,next_down,midpoint}` inline
Most float functions are marked `#[inline]` so any float symbols used by these functions only need to be provided if the function itself is used. RFL recently noticed that `next_up`, `next_down`, and `midpoint` for `f32` and `f64` are not inline, which causes linker errors when building with certain configurations <https://lore.kernel.org/all/20240806150619.192882-1-ojeda@kernel.org/>.
Add the missing attributes so the symbols should no longer be required.
Add tracking issue to core-pattern-type
While the actual `pattern_types` feature flag has an issue assigned, the exported macro and its module do not.
cc #123646
impl `Default` for collection iterators that don't already have it
There is a pretty strong precedent for implementing `Default` for collection iterators, and this does so for some where this implementation was missed.
I don't think this needs a separate ACP (since this precedent already exists, and these feel like they were just missed), however, it *will* need an FCP since these implementations are instantly stable.
Most float functions are marked `#[inline]` so any float symbols used by
these functions only need to be provided if the function itself is used.
RFL recently noticed that `next_up`, `next_down`, and `midpoint` for
`f32` and `f64` are not inline, which causes linker errors when building
with certain configurations [1].
Add the missing attributes so the symbols should no longer be required.
Cc: Gary Guo <gary@garyguo.net>
Reported-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/all/20240806150619.192882-1-ojeda@kernel.org/ [1]
Trivial grammar fix in const keyword docs
This PR makes a trivial fix to the wording of a sentence in the `const` keyword docs.
> `const` items looks remarkably similar to `static` items, [...]
Either this should be written as
> A `const` items looks remarkably similar to a `static` item, [...]
or "looks" should be changed to "look".
I have selected the smaller diff.
Add `f16` and `f128` math functions
This adds intrinsics and math functions for `f16` and `f128` floating point types. Support is quite limited and some things are broken so tests don't run on many platforms, but this provides a starting point.
> `const` items looks remarkably similar to `static` items, [...]
Either this should be written as
> A `const` items looks remarkably similar to a `static` item,
or "looks" should be changed to "look".
I have selected the smaller diff.
Forbid unused unsafe in vxworks-specific std modules
Tracking issue #127747
Adding deny(unsafe_op_in_unsafe_fn) in VxWorks specific files did not cause any error.
Most of VxWorks falls back on Unix libraries. So we'll have to wait for Unix changes.
r? ```@workingjubilee```
Instead of saying to "consider adding a `#[repr(C)]` or
`#[repr(transparent)]` attribute to this struct", we now tell users to
"Use `*const ffi::c_char` instead, and pass the value from
`CStr::as_ptr()`" when the type involved is a `CStr` or a `CString`.
Co-authored-by: Jieyou Xu <jieyouxu@outlook.com>
Rollup of 8 pull requests
Successful merges:
- #128026 (std:🧵 available_parallelism implementation for vxWorks proposal.)
- #128471 (rustdoc: Fix handling of `Self` type in search index and refactor its representation)
- #128607 (Use `object` in `run-make/symbols-visibility`)
- #128609 (Remove unnecessary constants from flt2dec dragon)
- #128611 (run-make: Remove cygpath)
- #128619 (Correct the const stabilization of `<[T]>::last_chunk`)
- #128630 (docs(resolve): more explain about `target`)
- #128660 (tests: more crashes)
r? `@ghost`
`@rustbot` modify labels: rollup
Correct the const stabilization of `<[T]>::last_chunk`
`<[T]>::first_chunk` became const stable in 1.77, but `<[T]>::last_chunk` was left out. This was fixed in 3488679768, which reached stable in 1.80, making `<[T]>::last_chunk` const stable as of that version, but it is documented as being const stable as 1.77. While this is what should have happened, the documentation should reflect what actually did happen.
Remove unnecessary constants from flt2dec dragon
The "dragon" `flt2dec` algorithm uses multi-precision multiplication by (sometimes large) powers of 10. It has precomputed some values to help with these calculations.
BUT:
* There is no need to store powers of 10 and 2 * powers of 10: it is trivial to compute the second from the first.
* We can save a chunk of memory by storing powers of 5 instead of powers of 10 for the large powers (and just shifting as appropriate).
* This also slightly speeds up the routines (by ~1-3%) since the intermediate products are smaller and the shift is cheap.
In this PR, we remove the unnecessary constants and do the necessary adjustments.
Relevant benchmarks before (on my Threadripper 3970X, x86_64-unknown-linux-gnu):
```
num::flt2dec::bench_big_shortest 137.92/iter +/- 2.24
num::flt2dec::strategy:🐉:bench_big_exact_12 2135.28/iter +/- 38.90
num::flt2dec::strategy:🐉:bench_big_exact_3 904.95/iter +/- 10.58
num::flt2dec::strategy:🐉:bench_big_exact_inf 47230.33/iter +/- 320.84
num::flt2dec::strategy:🐉:bench_big_shortest 3915.05/iter +/- 51.37
```
and after:
```
num::flt2dec::bench_big_shortest 137.40/iter +/- 2.03
num::flt2dec::strategy:🐉:bench_big_exact_12 2101.10/iter +/- 25.63
num::flt2dec::strategy:🐉:bench_big_exact_3 873.86/iter +/- 4.20
num::flt2dec::strategy:🐉:bench_big_exact_inf 47468.19/iter +/- 374.45
num::flt2dec::strategy:🐉:bench_big_shortest 3877.01/iter +/- 45.74
```
Implement cursors for `BTreeSet`
Tracking issue: https://github.com/rust-lang/rust/issues/107540
This is a straightforward wrapping of the map API, except that map's `CursorMut` does not make sense, because there is no value to mutate. Hence, map's `CursorMutKey` is wrapped here as just `CursorMut`, since it's unambiguous for sets and we don't normally speak of "keys". On the other hand, I can see some potential for confusion with `CursorMut` meaning different things in each module. I'm happy to take suggestions to improve that.
r? ````@Amanieu````
`<[T]>::first_chunk` became const stable in 1.77, but `<[T]>::last_chunk` was
left out. This was fixed in 3488679768, which reached stable in 1.80,
making `<[T]>::last_chunk` const stable as of that version, but it is
documented as being const stable as 1.77. While this is what should have
happened, the documentation should reflect what actually did happen.
Move the standard library to a separate workspace
This ensures that the Cargo.lock packaged for it in the rust-src component is up-to-date, allowing rust-analyzer to run cargo metadata on the standard library even when the rust-src component is stored in a read-only location as is necessary for loading crates.io dependencies of the standard library.
This also simplifies tidy's license check for runtime dependencies as it can now look at all entries in library/Cargo.lock without having to filter for just the dependencies of runtime crates. In addition this allows removing an exception in check_runtime_license_exceptions that was necessary due to the compiler enabling a feature on the object crate which pulls in a dependency not allowed for the standard library.
While cargo workspaces normally enable dependencies of multiple targets to be reused, for the standard library we do not want this reusing to prevent conflicts between dependencies of the sysroot and of tools that are built using this sysroot. For this reason we already use an unstable cargo feature to ensure that any dependencies which would otherwise be shared get a different -Cmetadata argument as well as using separate build dirs.
This doesn't change the situation around vendoring. We already have several cargo workspaces that need to be vendored. Adding another one doesn't change much.
There are also no cargo profiles that are shared between the root workspace and the library workspace anyway, so it doesn't add any extra work when changing cargo profiles.
This PR makes a number of changes to the UNIX randomness implementation:
* Use `io::Error` for centralized error handling
* Move the file-fallback logic out of the `getrandom`-specific module
* Stop redefining the syscalls on macOS and DragonFly, they have appeared in `libc`
* Add a `OnceLock` to cache the random device file descriptor
chore: refactor backtrace style in panic
# Refactor get_backtrace_style for better readability and potential performance improvements
This PR aims to improve the readability and maintainability of the `set_backtrace_style` and `get_backtrace_style` function.
Implement `UncheckedIterator` directly for `RepeatN`
This just pulls the code out of `next` into `next_unchecked`, rather than making the `Some` and `unwrap_unchecked`ing it.
And while I was touching it, I added a codegen test that `array::repeat` for something that's just `Clone`, not `Copy`, still ends up optimizing to the same thing as `[x; n]`: <https://rust.godbolt.org/z/YY3a5ajMW>.
The "dragon" `flt2dec` algorithm uses multi-precision multiplication by
(sometimes large) powers of 10. It has precomputed some values to help
with these calculations.
BUT:
* There is no need to store powers of 10 and 2 * powers of 10: it is
trivial to compute the second from the first.
* We can save a chunk of memory by storing powers of 5 instead of powers
of 10 for the large powers (and just shifting by 2 as appropriate).
* This also slightly speeds up the routines (by ~1-3%) since the
intermediate products are smaller and the shift is cheap.
In this PR, we remove the unnecessary constants and do the necessary
adjustments.
Relevant benchmarks before (on my Threadripper 3970X, x86_64-unknown-linux-gnu):
```
num::flt2dec::bench_big_shortest 137.92/iter +/- 2.24
num::flt2dec::strategy:🐉:bench_big_exact_12 2135.28/iter +/- 38.90
num::flt2dec::strategy:🐉:bench_big_exact_3 904.95/iter +/- 10.58
num::flt2dec::strategy:🐉:bench_big_exact_inf 47230.33/iter +/- 320.84
num::flt2dec::strategy:🐉:bench_big_shortest 3915.05/iter +/- 51.37
```
and after:
```
num::flt2dec::bench_big_shortest 137.40/iter +/- 2.03
num::flt2dec::strategy:🐉:bench_big_exact_12 2101.10/iter +/- 25.63
num::flt2dec::strategy:🐉:bench_big_exact_3 873.86/iter +/- 4.20
num::flt2dec::strategy:🐉:bench_big_exact_inf 47468.19/iter +/- 374.45
num::flt2dec::strategy:🐉:bench_big_shortest 3877.01/iter +/- 45.74
```
Revert recent changes to dead code analysis
This is a revert to recent changes to dead code analysis, namely:
* efdf219 Rollup merge of #128104 - mu001999-contrib:fix/128053, r=petrochenkov
* a70dc297a8 Rollup merge of #127017 - mu001999-contrib:dead/enhance, r=pnkfelix
* 31fe9628cf Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix
* 2724aeaaeb Rollup merge of #126618 - mu001999-contrib:dead/enhance, r=pnkfelix
* 977c5fd419 Rollup merge of #126315 - mu001999-contrib:fix/126289, r=petrochenkov
* 13314df21b Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix
There is an additional change stacked on top, which suppresses false-negatives that were masked by this work. I believe the functions that are touched in that code are legitimately unused functions and the types are not reachable since this `AnonPipe` type is not publically reachable -- please correct me if I'm wrong cc `@NobodyXu` who added these in ##127153.
Some of these reverts (#126315 and #126618) are only included because it makes the revert apply cleanly, and I think these changes were only done to fix follow-ups from the other PRs?
I apologize for the size of the PR and the churn that it has on the codebase (and for reverting `@mu001999's` work here), but I'm putting this PR up because I am concerned that we're making ad-hoc changes to fix bugs that are fallout of these PRs, and I'd like to see these changes reimplemented in a way that's more separable from the existing dead code pass. I am happy to review any code to reapply these changes in a more separable way.
cc `@mu001999`
r? `@pnkfelix`
Fixes#128272Fixes#126169
Add `#[must_use]` to some `into_raw*` functions.
cc #121287
r? ``@cuviper``
Adds `#[must_use = "losing the pointer will leak memory"]`[^1] to `Box::into_raw(_with_allocator)`, `Vec::into_raw_parts(_with_alloc)`, `String::into_raw_parts`[^2], and `rc::{Rc, Weak}::into_raw_with_allocator` (Rc's normal `into_raw` and all of `Arc`'s `into_raw*`s are already `must_use`).
Adds `#[must_use = "losing the raw <resource name may leak resources"]` to `IntoRawFd::into_raw_fd`, `IntoRawSocket::into_raw_socket`, and `IntoRawHandle::into_raw_handle`.
[^1]: "*will* leak memory" may be too-strong wording (since `Box`/`Vec`/`String`/`rc::Weak` might not have a backing allocation), but I left it as-is for simplicity and consistency.
[^2]: `String::into_raw_parts`'s `must_use` message is changed from the previous (possibly misleading) "`self` will be dropped if the result is not used".
Added SHA512, SM3, SM4 target-features and `sha512_sm_x86` feature gate
This is an effort towards #126624. This adds support for these 3 target-features and introduces the feature flag `sha512_sm_x86`, which would gate these target-features and the yet-to-be-implemented detection and intrinsics in stdarch.
This ensures that the Cargo.lock packaged for it in the rust-src
component is up-to-date, allowing rust-analyzer to run cargo metadata on
the standard library even when the rust-src component is stored in a
read-only location as is necessary for loading crates.io dependencies of
the standard library.
This also simplifies tidy's license check for runtime dependencies as it
can now look at all entries in library/Cargo.lock without having to
filter for just the dependencies of runtime crates. In addition this
allows removing an exception in check_runtime_license_exceptions that
was necessary due to the compiler enabling a feature on the object crate
which pulls in a dependency not allowed for the standard library.
While cargo workspaces normally enable dependencies of multiple targets
to be reused, for the standard library we do not want this reusing to
prevent conflicts between dependencies of the sysroot and of tools that
are built using this sysroot. For this reason we already use an unstable
cargo feature to ensure that any dependencies which would otherwise be
shared get a different -Cmetadata argument as well as using separate
build dirs.
This doesn't change the situation around vendoring. We already have
several cargo workspaces that need to be vendored. Adding another one
doesn't change much.
There are also no cargo profiles that are shared between the root
workspace and the library workspace anyway, so it doesn't add any extra
work when changing cargo profiles.
Rewrite binary search implementation
This PR builds on top of #128250, which should be merged first.
This restores the original binary search implementation from #45333 which has the nice property of having a loop count that only depends on the size of the slice. This, along with explicit conditional moves from #128250, means that the entire binary search loop can be perfectly predicted by the branch predictor.
Additionally, LLVM is able to unroll the loop when the slice length is known at compile-time. This results in a very compact code sequence of 3-4 instructions per binary search step and zero branches.
Fixes#53823Fixes#115271
raw_eq: using it on bytes with provenance is not UB (outside const-eval)
The current behavior of raw_eq violates provenance monotonicity. See https://github.com/rust-lang/rust/pull/124921 for an explanation of provenance monotonicity. It is violated in raw_eq because comparing bytes without provenance is well-defined, but adding provenance makes the operation UB.
So remove the no-provenance requirement from raw_eq. However, the requirement stays in-place for compile-time invocations of raw_eq, that indeed cannot deal with provenance.
Cc `@rust-lang/opsem`
Due to a LLVM bug, `f128` math functions link successfully but LLVM
chooses the wrong symbols (`long double` symbols rather than those for
binary128).
Since this is a notable problem that may surprise a number of users, add
a note about it.
Link: https://github.com/llvm/llvm-project/issues/44744
`min`, `max`, and similar functions require external math routines. Add
these under the same gates as `std` math functions (`reliable_f16_math`
and `reliable_f128_math`).
This adds missing functions for math operations on the new float types.
Platform support is pretty spotty at this point, since even platforms
with generally good support can be missing math functions.
`std/build.rs` is updated to reflect this.
android: Remove libstd hacks for unsupported Android APIs
Our minimum supported API version is 21, remove hacks to support older Android APIs.
try-job: arm-android
r? tgross35
Rollup of 7 pull requests
Successful merges:
- #123813 (Add `REDUNDANT_IMPORTS` lint for new redundant import detection)
- #126697 ([RFC] mbe: consider the `_` in 2024 an expression)
- #127159 (match lowering: Hide `Candidate` from outside the lowering algorithm)
- #128244 (Peel off explicit (or implicit) deref before suggesting clone on move error in borrowck, remove some hacks)
- #128431 (Add myself as VxWorks target maintainer for reference)
- #128438 (Add special-case for [T, 0] in dropck_outlives)
- #128457 (Fix docs for OnceLock::get_mut_or_init)
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup sys module to match house style
This moves a test file out of sys as it's just testing std types. Also cleans up some assorted bits including making the `use` statements match the house style.
std: implement the `once_wait` feature
Tracking issue: #127527
This additionally adds a `wait_force` method to `Once` that doesn't panic on poison.
I also took the opportunity and cleaned up up the code of the queue-based implementation a bit.
Match LLVM ABI in `extern "C"` functions for `f128` on Windows
As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.
I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.
Tracking issue: #116909
try-job: x86_64-msvc
try-job: x86_64-mingw
- Use if the implementation of [`Ord`] for `T`
language
- Link to total order wiki page
- Rework total order help and examples
- Improve language to be more precise and less
prone to misunderstandings.
- Fix usage of `sort_unstable_by` in `sort_by`
example
- Fix missing author mention
- Use more consistent example input for sort
- Use more idiomatic assert_eq! in examples
- Use more natural "comparison function" language
instead of "comparator function"
This restores the original binary search implementation from #45333
which has the nice property of having a loop count that only depends on
the size of the slice. This, along with explicit conditional moves
from #128250, means that the entire binary search loop can be perfectly
predicted by the branch predictor.
Additionally, LLVM is able to unroll the loop when the slice length is
known at compile-time. This results in a very compact code sequence of
3-4 instructions per binary search step and zero branches.
Fixes#53823
Rollup of 4 pull requests
Successful merges:
- #127574 (elaborate unknowable goals)
- #128141 (Set branch protection function attributes)
- #128315 (Fix vita build of std and forbid unsafe in unsafe in the os/vita module)
- #128339 ([rustdoc] Make the buttons remain when code example is clicked)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `select_unpredictable` to force LLVM to use CMOV
Since https://reviews.llvm.org/D118118, LLVM will no longer turn CMOVs into branches if it comes from a `select` marked with an `unpredictable` metadata attribute.
This PR introduces `core::intrinsics::select_unpredictable` which emits such a `select` and uses it in the implementation of `binary_search_by`.
Optimize empty case in Vec::retain
While profiling some code that happens to call Vec::retain() in a tight loop, I noticed more runtime than expected in retain, even in a bench case where the vector was always empty. When I wrapped my call to retain in `if !myvec.is_empty()` I saw faster execution compared with doing retain on an empty vector.
On closer inspection, Vec::retain is doing set_len(0) on itself even when the vector is empty, and then resetting the length again in BackshiftOnDrop::drop.
Unscientific screengrab of a flamegraph illustrating how we end up spending time in set_len and drop:
Clean and enable `rustdoc::unescaped_backticks` for `core/alloc/std/test/proc_macro`
I am not sure if the lint is supposed to be "ready enough" (since it is `allow` by default), but it does catch a couple issues in `core` (`alloc`, `std`, `test` and `proc_macro` are already clean), so I propose making it `warn` in all the crates rendered in the website.
Cc: `@GuillaumeGomez`
Update compiler_builtins to 0.1.114
The `weak-intrinsics` feature was removed from compiler_builtins in https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the `compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.
In https://github.com/rust-lang/compiler-builtins/pull/593, some builtins for f16/f128 were added. These don't work for all compiler backends, so add a `compiler-builtins-no-f16-f128` feature and disable it for cranelift and gcc.
std: unsafe-wrap personality::dwarf::eh
Moves the forbiddance up a little. This is another largely whitespace diff, except for hoisting some variable declarations to allow enclosing the `unsafe {}` scope fully and make it clearer where the bounds of some temporaries are.
Replace `io::Cursor::{remaining_slice, is_empty}`
This is a late follow up to the concerns raised in https://github.com/rust-lang/rust/issues/86369.
https://github.com/rust-lang/rust/issues/86369#issuecomment-953096691
> This API seems focussed on the `Read` side of things. When `Seek`ing around and `Write`ing data, `is_empty` becomes confusing and `remaining_slice` is not very useful. When writing, the part of the slice before the cursor is much more interesting. Maybe we should have functions for both? Or a single function that returns both slices? (If we also have a `mut` version, a single function would be useful to allow mutable access to both sides at once.)
New feature name: `cursor_remaining` > `cursor_split`.
Added functions:
```rust
fn split(&self) -> (&[u8], &[u8]);
// fn before(&self) -> &[u8];
// fn after(&self) -> &[u8];
fn split_mut(&mut self) -> (&mut [u8], &mut [u8]);
// fn before_mut(&mut self) -> &mut [u8];
// fn after_mut(&mut self) -> &mut [u8];
```
A question was raised in https://github.com/rust-lang/rust/issues/86369#issuecomment-927124211 about whether to return a lifetime that would reflect the lifetime of the underlying bytes (`impl Cursor<&'a [u8]> { fn after(&self) -> &'a [u8] }`). The downside of doing this would be that it would not be possible to implement these functions generically over `T: AsRef<[u8]>`.
## Update
Based on the review, before* and after* methods where removed.
Matthias Krüger