Use zero for initialized Once state
By re-labeling which integer represents which internal state for `Once` we can ensure that the initialized state is the all-zero state. This is beneficial because some CPU architectures (such as Arm) have specialized instructions to specifically branch on non-zero, and checking for the initialized state is by far the most important operation.
As an example, take this:
```rust
use std::sync::atomic::{AtomicU32, Ordering};
const INIT: u32 = 3;
#[inline(never)]
#[cold]
pub fn slow(state: &AtomicU32) {
state.store(INIT, Ordering::Release);
}
pub fn ensure_init(state: &AtomicU32) {
if state.load(Ordering::Acquire) != INIT {
slow(state)
}
}
```
If `INIT` is 3 (as is currently the state for `Once`), we see the following assembly on `aarch64-apple-darwin`:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cmp w8, #3
b.ne LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
By changing the `INIT` state to zero we get the following:
```asm
example::ensure_init::h332061368366e313:
ldapr w8, [x0]
cbnz w8, LBB1_2
ret
LBB1_2:
b example::slow::ha042bd6a4f33724e
```
So this PR saves 1 instruction every time a `LazyLock` gets accessed on platforms such as these.
std: move NuttX to use arc4random for random number generation
arc4random support in libc merged in https://github.com/rust-lang/libc/pull/4464, so:
* Move `target_os = "nuttx"` from unix_legacy to arc4random section
* This aligns NuttX with other POSIX-compliant systems that support arc4random
* Improves random number generation quality on NuttX by using the system's built-in arc4random implementation instead of legacy fallback methods
NuttX supports arc4random_buf which provides better entropy and security compared to the legacy random number generation methods.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143403 (Port several trait/coherence-related attributes the new attribute system)
- rust-lang/rust#143633 (fix: correct assertion to check for 'noinline' attribute presence before removal)
- rust-lang/rust#143647 (Clarify and expand documentation for std::sys_common dependency structure)
- rust-lang/rust#143716 (compiler: doc/comment some codegen-for-functions interfaces)
- rust-lang/rust#143747 (Add target maintainer information for aarch64-unknown-linux-musl)
- rust-lang/rust#143759 (Fix typos in function names in the `target_feature` test)
- rust-lang/rust#143767 (Bump `src/tools/x` to Edition 2024 and some cleanups)
- rust-lang/rust#143769 (Remove support for SwitchInt edge effects in backward dataflow)
- rust-lang/rust#143770 (build-helper: clippy fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
Clarify and expand documentation for std::sys_common dependency structure
This PR makes a minor improvement to the module-level documentation of std::sys_common:
Replaces the lowercase “dag” with the more standard and explicit form “DAG (Directed Acyclic Graph)” for clarity.
* Move `target_os = "nuttx"` from unix_legacy to arc4random section
* This aligns NuttX with other POSIX-compliant systems that support arc4random
* Improves random number generation quality on NuttX by using the system's
built-in arc4random implementation instead of legacy fallback methods
NuttX supports arc4random_buf which provides better entropy and security
compared to the legacy random number generation methods.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Add a setsid method to the CommandExt trait so that callers can create
a process in a new session and process group whilst still using the
POSIX spawn fast path.
Co-Authored-By: Harvey Hunt <harveyhunt@fb.com>
The clock_nanosleep support is there to allow code using `sleep_until`
to run under Miri. Therefore the implementation is minimal.
- Only the clocks REALTIME and MONOTONIC are supported. The first is supported simply
because it was trivial to add not because it was needed for sleep_until.
- The only supported flag combinations are no flags or TIMER_ABSTIME only.
If an unsupported flag combination or clock is passed in this throws
unsupported.
Using clock nanosleep leads to more accurate sleep times on platforms
where it is supported.
To enable using clock_nanosleep this makes `sleep_until` platform
specific. That unfortunatly requires identical placeholder
implementations for the other platforms (windows/mac/wasm etc).
we will land platform specific implementations for those later. See the
`sleep_until` tracking issue.
This requires an accessors for the Instant type. As that accessor is only
used on the platforms that have clock_nanosleep it is marked as allow_unused.
32bit time_t targets do not use clock_nanosleep atm, they instead rely
on the same placeholder as the other platforms. We could make them
use clock_nanosleep too in the future using `__clock_nanosleep_time64`.
__clock_nanosleep_time64 is documented at:
https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
Make __rust_alloc_error_handler_should_panic a function
Fixesrust-lang/rust#143253
`__rust_alloc_error_handler_should_panic` is a static but was being exported as a function.
For most targets this doesn't matter, but Arm64EC Windows uses different decorations for exported variables vs functions, hence it fails to link when `-Z oom=abort` is enabled.
We've had issues in the past with statics like this (see rust-lang/rust#141061) but the tldr; is that Arm64EC needs symbols correctly exported as either a function or data, and data MUST and MUST ONLY be marked `dllimport` when the symbol is being imported from another binary, which is non-trivial to calculate for these compiler-generated statics.
So, instead, the easiest thing to do is to make `__rust_alloc_error_handler_should_panic` a function instead.
Since `__rust_alloc_error_handler_should_panic` isn't involved in any linking shenanigans, I've marked it as `AlwaysInline` with the hopes that the various backends will see that it is just returning a constant and perform the same optimizations as the previous implementation.
r? `@bjorn3`
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
Workaround for memory unsafety in third party DLLs
Resolvesrust-lang/rust#143078
Note that we can't make any guarantees if third parties intercept OS functions and don't implement them according to the documentation. However, I think it's practical to attempt mitigations when issues are encountered in the wild and the mitigation itself isn't too invasive.
update internal `send_signal` comment
the vxwork did not have the old comment updated in rust-lang/rust#141990 so update here;
signaling -> sending signals to because the latter reads better to me.
std::net: adding `unix_socket_exclbind` feature for solaris/illumos.
allows to have a tigher control over the binding exclusivness of the socket.
ACP: https://github.com/rust-lang/libs-team/issues/366
Fix RwLock::try_write documentation for WouldBlock condition
Fix RwLock::try_write documentation for WouldBlock condition
The documentation incorrectly stated that try_write only fails when
'already locked exclusively', but it actually fails when there are
either shared (read) or exclusive (write) locks.
Fixesrust-lang/rust#142852
Windows: make `read_dir` stop iterating after the first error is encountered
This also essentially makes the `ReadDir` iterator fused. Which I think is pretty much what people expect anyway.
[`FindNextFileW`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilew) doesn't document what happens if you call it after iteration ends or after an error so we're probably in implementation defined territory at that point.
Jakub Beránek