Add experimental `backtrace-trace-only` std feature
This experimentally allows building std with backtrace but without symbolisation. It does not affect stable and requires build-std to use. This doesn't change the backtrace crate itself so relies on the optimizer to remove the unused parts.
Example usage:
```toml
# .cargo/config.toml
[unstable]
build-std = ["core", "alloc", "panic_unwind", "std"]
build-std-features = ["backtrace", "backtrace-trace-only", "panic-unwind"]
```
```toml
# Cargo.toml
[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
```
Ideally we should split the backtrace feature into `backtrace-trace` and `backtrace-symbolize` (with the latter dependent on the former) because Cargo features tend to work better when they're positive rather than negative. But I'm keen for this experiment not to break existing users.
cc ``@joshtriplett``
Updates to random number generation APIs
Updates based on discussions about random number generation.
- Add comment on `RandomSource::fill_bytes` about multiple calls, to allow
efficient implementations for random sources that generate a word at a time.
- Drop the `Random` trait in favor of `Distribution<T>`, which will let people
make calls like random(1..=6), and which allows for future expansion to
non-uniform distributions, as well as floating-point. (For now, this is only
implemented for `RangeFull`, to get the interface in place. Subsequent PRs
will implement it for other range types.)
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.
* 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
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
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.
Implement send_signal for unix child processes
Tracking issue: rust-lang/rust#141975
There are two main differences between my implementation and the Public API section of the tracking issue. ~First, `send_signal` requires a mutable reference, like `Child::kill`.~ Second, `ChildExt` has `Sealed` as a supertrait, bringing it more in line with other extension traits like `CommandExt`.
try-job: `dist-various*`
try-job: `test-various*`
Handle win32 separator for cygwin paths
This PR handles a issue that cygwin actually supports Win32 path, so we need to handle the Win32 prefix and separaters.
r? `@mati865`
cc `@jeremyd2019`
~~Not sure if I should handle the prefix like the windows target... Cygwin *does* support win32 paths directly going through the APIs, but I think it's not the recommended way.~~
Here I just use `cygwin_conv_path` because it handles both cygwin and win32 paths correctly and convert them into absolute POSIX paths.
UPDATE: Windows path prefix is handled.
Fix AIX build
Fixrust-lang/rust#141543.
`getenv` was moved out of this file to `sys::env::getenv` in rust-lang/rust#140143. Replace its usage with `std::env::var_os`, the publicly exposed version. This matches the other usages of the same function in this file.
It uses the file metadata on Unix with a fallback for files incorrectly
reported as zero-sized. It uses `GetFileSizeEx` on Windows.
This reduces the number of syscalls needed for determining the file size
of an open file from 3 to 1.
make `OsString::new` and `PathBuf::new` unstably const
Since #129041, `String::into_bytes` is `const`, which allows making `OsString::new` and `PathBuf::new` unstably const now.
Not sure what the exact process for this is; does it need an ACP?
std: abort the process on failure to allocate a TLS key
The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see https://github.com/rust-lang/rust/issues/140798#issuecomment-2872307377). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.
Do not move thread-locals before dropping
Fixesrust-lang/rust#140816. I also (potentially) improved the speed of `get_or_init` a bit by having an explicit hot/cold path.
We still move the value before dropping in the event of a recursive initialization (leading to double-initialization with one value being silently dropped). This is the old behavior, but changing this to panic instead would involve changing tests and also the other OS-specific `thread_local/os.rs` implementation, which is more than I'd like in this PR.
