library: std: motor: use OS' process::exit in abort_internal
abort_internal() is used in panics; if it calls core::intrinsics::abort(), the process triggers an invalid op code (on x86_64), which is a much harder "abort" than a user-controlled exit via a panic.
Most other OSes don't use core::intrinsics::abort() here, but either libc::abort(), or a native OS abort/exit API.
abort_internal() is used in panics; if it calls
core::intrinsics::abort(), the process triggers an
invalid op code (on x86_64), which is a much harder "abort"
than a user-controlled exit via a panic.
Most other OSes don't use core::intrinsics::abort() here,
but either libc::abort(), or a native OS abort/exit API.
`BorrowedCursor`: make `init` a boolean
This PR changes uninitialized bytes tracking in `BorrowedBuf` from being byte-wise to being buffer-wise.
I've put all the API around `init` a new unstable feature `borrowed_buf_init`, to split the part that needs it and the part that doesn't. It will avoids accidental stabilization of this part.
I'm not really convinced of the rename of `advance_unchecked` to `advance`, but I did it anyway. The old `advance` was kept as `advance_checked`.
Alternative of rust-lang/rust#148937
Cc rust-lang/rust#78485rust-lang/rust#117693
Cc @joshtriplett
r? @Amanieu
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#147552 ([Debugger Visualizers] Optimize lookup behavior)
- rust-lang/rust#154052 (float: Fix panic at max exponential precision)
- rust-lang/rust#154706 (fix compilation of time/hermit.rs)
- rust-lang/rust#154707 (Make `substr_range` and `subslice_range` return the new `Range` type)
- rust-lang/rust#154767 (triagebot: roll library reviewers for `{coretests,alloctests}`)
- rust-lang/rust#154797 (bootstrap: Include shorthand aliases in x completions)
Panic/return false on overflow in no_threads read/try_read impl
As per discussion with Mark in rust-lang/rust#153555, it's possible for `no_threads` impl of `RwLock` to trigger a silent overflow on `RwLock::read`/`RwLock::try_read` if we try to acquire more than `isize::MAX` read locks. This PR adds an explicit panic/return false when our read lock counter is at `isize::MAX` for `RwLock::read`/`RwLock::try_read`; the message is similar to that of sys/sync/rwlock/futex.rs [here](https://github.com/rust-lang/rust/blob/fb27476aaf1012f1f6ace6306f9b990e0d989c31/library/std/src/sys/sync/rwlock/futex.rs#L143).
Fix SGX delayed host lookup via ToSocketAddr
rust-lang/rust#146541 introduced a regression in the `x86_64-fortanix-unknown-sgx` target, where arguments to TcpStream::connect and TcpListener::bind are no longer being passed down correctly to the underlying platform, resulting in connection/bind failures
* Add a test for the desired behavior (this test passes on Rust 1.33 through 1.91)
* Refactor lookup_host logic again
Fixesrust-lang/rust#152848
cc @joboet
std::net: clamp linger timeout value to prevent silent truncation.
Duration::as_secs() returns u64 but l_linger field type is narrower, c_int on most unix platforms, c_ushort on cygwin and windows. clamping before the cast, consistent with how set_timeout handles this.
Update libc to v0.2.183
Follow-up of https://github.com/rust-lang/rust/pull/150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
Prevent no_threads RwLock's write() impl from setting mode to -1 when it is locked for reading
In my time updating the docs to `std::sync::RwLock` and adding a test verifying that max reader count is reachable in rust-lang/rust#153555, I noticed that the no_threads RwLock's `write()` implementation always sets the `mode` to `-1` (denoting writer locked) even though it could be reader locked. I feel like that's logically incorrect and that it should only be setting the `mode` to `-1` when we know that the mode is unlocked (`0`); `write()` should mirror the code that `read()` and `try_read()` has with `try_write()`.
For reference on read/try_read and write/try_write current implementations:
```rust
#[inline]
pub fn read(&self) {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
} else {
rtabort!("rwlock locked for writing");
}
}
#[inline]
pub fn try_read(&self) -> bool {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
true
} else {
false
}
}
#[inline]
pub fn write(&self) {
if self.mode.replace(-1) != 0 { // <-- This behavior logically does something different than what `try_write` does
rtabort!("rwlock locked for reading")
}
}
#[inline]
pub fn try_write(&self) -> bool {
if self.mode.get() == 0 {
self.mode.set(-1);
true
} else {
false
}
}
```
r? @jhpratt
Use common Timestamp impl in Hermit (attempt 2)
The goal is to have less code to maintain, so to be able to make changes easier.
Previous attempt https://github.com/rust-lang/rust/pull/148847 was asked to postpone because there was restructure of code, which is complete now.
r? joboet
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
Skip stack_start_aligned for immediate-abort
This improves startup performance by 16%, shown by an optimized hello-world program. glibc's `pthread_getattr_np` performs expensive syscalls when reading `/proc/self/maps`. That is all wasted with `panic = immediate-abort` active because `init()` immediately discards the return value from `install_main_guard()`. A similar improvement can be seen in environments that don't have `/proc`. This change is safe because the immediately succeeding comment says that we rely on Linux's "own stack-guard mechanism".
Tracking issue: https://github.com/rust-lang/rust/issues/147286
# Benchmark
Set it up with `cargo new hello-world2`, and replace these files:
```toml
# Cargo.toml
cargo-features = ["panic-immediate-abort"]
[package]
name = "hello-world"
version = "0.1.0"
edition = "2024"
[profile.release]
lto = true
panic = "immediate-abort"
codegen-units = 1
opt-level = "z"
strip = true
# .cargo/config.toml
[unstable]
build-std = ["std"]
```
## Before
```console
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
Time (mean ± σ): 524.8 µs ± 65.1 µs [User: 276.1 µs, System: 187.0 µs]
Range (min … max): 446.4 µs … 975.5 µs 3996 runs
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
Time (mean ± σ): 519.4 µs ± 65.8 µs [User: 282.1 µs, System: 177.7 µs]
Range (min … max): 443.2 µs … 830.5 µs 3612 runs
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
Time (mean ± σ): 520.0 µs ± 64.3 µs [User: 277.1 µs, System: 182.1 µs]
Range (min … max): 447.1 µs … 1001.3 µs 3804 runs
```
For a visualization of the problem, run `cargo +stage1 build --release && perf record --call-graph dwarf -F max ./target/release/hello-world2 && perf script | inferno-collapse-perf | inferno-flamegraph > flamegraph.svg`:
<img width="3832" height="1216" alt="flamegraph with 17.41% __pthread_getattr_np" src="https://github.com/user-attachments/assets/acc2286e-1582-4772-9e3b-68b5c35e3e70" />
## After
```console
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2Benchmark 1: target/release/hello-world2
Time (mean ± σ): 444.7 µs ± 57.3 µs [User: 257.4 µs, System: 130.2 µs]
Range (min … max): 379.4 µs … 1289.3 µs 3893 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
Time (mean ± σ): 452.3 µs ± 60.7 µs [User: 261.5 µs, System: 133.5 µs]
Range (min … max): 374.9 µs … 1512.4 µs 4177 runs
Warning: Statistical outliers were detected. Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the '--warmup' or '--prepare' options.
home@daniel-desktop3:~/CLionProjects/hello-world2$ hyperfine -N target/release/hello-world2
Benchmark 1: target/release/hello-world2
Time (mean ± σ): 441.2 µs ± 56.1 µs [User: 256.2 µs, System: 128.8 µs]
Range (min … max): 375.0 µs … 760.4 µs 4032 runs
```
std: move `sys::pal::os` to `sys::paths`
Part of rust-lang/rust#117276.
After rust-lang/rust#150723, rust-lang/rust#153130, rust-lang/rust#153341 and rust-lang/rust#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang/rust#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`.
~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~
I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves.
CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)
Fix environ on FreeBSD with cdylib targets that use -Wl,--no-undefined .
Instead of relying on the linker to find the 'environ' symbol, use dlsym. This fixes using `environ` from cdylibs that link with `-Wl,--no-undefined` .
Fixesrust-lang/rust#153451
Sponsored by: ConnectWise
Allow passing `expr` metavariable as `cfg` predicate
This PR allows expanding `expr` metavariables inside the configuration predicates of `cfg` and `cfg_attr` invocations.
For example, the following code will now compile:
```rust
macro_rules! mac {
($e:expr) => {
#[cfg_attr($e, inline)]
#[cfg($e)]
fn func() {}
#[cfg(not($e))]
fn func() {
panic!()
}
}
}
mac!(any(unix, feature = "foo"));
```
There is currently no `macro_rules` fragment specifier that can represent all valid `cfg` predicates. `meta` comes closest, but excludes `true` and `false`. By fixing that, this change makes it easier to write declarative macros that parse `cfg` or `cfg_attr` invocations, for example https://github.com/rust-lang/rust/pull/146281/.
@rustbot label T-lang needs-fcp A-attributes A-cfg A-macros
This improves startup performance by 16%, shown by an optimized
hello-world program. glibc's `pthread_getattr_np` performs expensive
syscalls when reading `/proc/self/maps`. That is all wasted with
`panic = immediate-abort` active because `init()` immediately discards
the return value from `install_main_guard()`. A similar improvement can
be seen in environments that don't have `/proc`. This change is safe
because the immediately succeeding comment says that we rely on Linux's
"own stack-guard mechanism".
Fix bootstrap rust build failure for vxworks
Fixesrust-lang/rust#153332
Starting with VxWorks 25.09, struct stat was updated to use struct timespec instead of time_t for timestamp fields.
The following changes were made in libc in the commit [libc](https://github.com/rust-lang/libc/pull/4781).
As a result, when performing a bootstrap build with VxWorks ≥ 25.09, libc no longer exposes the fields st_mtime, st_atime, and st_ctime, as they are conditionally compiled in src/vxworks/mod.rs here [libc](https://github.com/rust-lang/libc/blob/56caa81b6b433c49c5704bf0400a02d428cfacda/src/vxworks/mod.rs#L229). This causes the build to fail.
For VxWorks versions earlier than 25.09, the build completes successfully without errors.
This PR resolves the issue by detecting the WIND_RELEASE_ID environment variable (which is set in the VxWorks build environment) and conditionally guarding the affected functions in the two additional files where the errors originate.
- `From<T> for ThinBox<T>`
- `From<T> for UniqueRc<T>`
- `From<T> for UniqueArc<T>`
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
std: organise `sys::pal::os`
Continuing rust-lang/rust#153341, this moves around some functions in `sys::pal`, so that `pal::os` only contains standard-path-related code (which I'll move later as part of rust-lang/rust#117276).
Best reviewed commit-by-commit.
std: add wasm64 to sync::Once and thread_parking atomics cfg guards
When targeting `wasm64-unknown-unknown` with atomics enabled, `std::sync::Once` and `thread_parking` fall through to the `no_threads`/`unsupported` implementations because the cfg guards only check for `wasm32`. This causes worker threads to panic with `unreachable` at runtime. The underlying futex implementations already handle both wasm32 and wasm64 correctly, only the cfg guards were missing wasm64.
I tested this manually with a multithreaded wasm64 application ([o1js](https://github.com/o1-labs/o1js/)) compiled with `-Z build-std=panic_abort,std` and `-C target-feature=+atomics,+bulk-memory,+mutable-globals`
Related: rust-lang/rust#83879rust-lang/rust#77839
Happy to adjust anything based on feedback
* consolidate various representations of separators in std::sys::path
into a single macro_rules invocation per platform to save
transcription errors
* make `std::path::is_separator()` const
* new constants `std::path::{SEPARATORS, SEPARATORS_STR}`
Jonathan Brouwer