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
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.
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. Also disable it for LLVM targets that don't
support it.
There are only 3 cases across the crates rendered in the website (`core`,
`alloc`, `std`, `proc_macro` and `test`), and they are all in `core`.
Clean them up, so that the lint can be enabled in the next commit.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add links from `assert_eq!` docs to `debug_assert_eq!`, etc.
This adds information and links from the docs for the following macros to their debug-only versions:
* `assert_eq!`
* `assert_ne!`
* `assert_matches!`
This matches the existing documentation for the `assert!` macro.
Stabilize `const_waker`
Closes: https://github.com/rust-lang/rust/issues/102012.
For `local_waker` and `context_ext` related things, I just ~~moved them to dedicated feature gates and reused their own tracking issue (maybe it's better to open a new one later, but at least they should not be tracked under https://github.com/rust-lang/rust/issues/102012 from the beginning IMO.)~~ reused their own feature gates as suggested by ``@tgross35.``
``@rustbot`` label: +T-libs-api
r? libs-api
add `is_multiple_of` for unsigned integer types
tracking issue: https://github.com/rust-lang/rust/issues/128101
This adds the `.is_multiple_of` method on unsigned integers.
Returns `true` if `self` is an integer multiple of `rhs`, and false otherwise.
This function is equivalent to `self % rhs == 0`, except that it will not panic for `rhs == 0`. Instead, `0.is_multiple_of(0) == true`, and for any non-zero `n`, `n.is_multiple_of(0) == false`.
Fix doc nits
Many tiny changes to stdlib doc comments to make them consistent (for example "Returns foo", rather than "Return foo"), adding missing periods, paragraph breaks, backticks for monospace style, and other minor nits.
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`.
[illumos/solaris] set MSG_NOSIGNAL while writing to sockets
Both these platforms have MSG_NOSIGNAL available, and we should set it for socket writes in the event that the SIGPIPE handler has been reset to SIG_DFL (i.e. terminate the process).
I've verified via a quick program at
https://github.com/sunshowers/msg-nosignal-test/ that even when the SIGPIPE handler is reset to SIG_DFL, writes to closed TCP sockets now error out with EPIPE. (Under ordinary circumstances UDP writes won't cause MSG_NOSIGNAL.)
However, I couldn't find any existing tests which verified the MSG_NOSIGNAL behavior.
