Defer codegen for the VaList Drop impl to actual uses
This allows compiling libcore with codegen backends that don't actually implement VaList like cg_clif.
Add APIs for dealing with titlecase
ACP: https://github.com/rust-lang/libs-team/issues/354
Tracking issue: https://github.com/rust-lang/rust/issues/153892
r? libs-api
@rustbot label T-libs -T-libs-api A-unicode
~~The last commit has some insta-stable `PartialEq` impls, therefore: @rustbot label -needs-fcp
Alternatively, I could split those out into a follow-up PR.~~ (Edit: will do in follow-up)
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
```
docs(fs): Clarify That File::lock Coordinates Across Processes
### Summary:
The documentation for `lock`, `lock_shared`, `try_lock`, and `try_lock_shared` did not make it clear that these are OS level file locks that coordinate access across processes, not just between handles within the current process.
Add "in this or any other process" to each method's existing description to clarify this.
Fixesrust-lang/rust#153618
r? @Mark-Simulacrum
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)
Move `freeze_*` methods to `OpenOptionsExt2`
Move the unstable `freeze_last_access_time` and `freeze_last_write_time` from `OpenOptionsExt` to a new `OpenOptionsExt2` trait. This should fixrust-lang/rust#153486.
Lifted intersperse and intersperse_with Fused transformation and updated documentation + tests
This PR once again builds on top of rust-lang/rust#152855. From the discussion in rust-lang/rust#152855, libs team came to the conclusion that `intersperse`/`intersperse_with` shouldn't transform the given iterator to a fused iterator always and a separator should be emitted between `Some(_)` items for non fused iterators (particularly just right before the subsequent `Some(_)`).
On top of the change Zakarumych added in the PR, I lifted the `FusedIterator` trait and transformation of the inner `iter` for `Intersperse`/`IntersperseWith`, so that we can display this behavior. I've adjusted the documentation and tests accordingly to reflect this change as well.
r? @jhpratt
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
Optimize BTreeMap::append() using CursorMut
Since [`BTreeMap::merge`](https://github.com/rust-lang/rust/pull/152418#issuecomment-3959764862) uses `CursorMut` to avoid reconstructing the map from scratch and instead inserting other `BTreeMap` at the right places or overwriting the value in self `BTreeMap` on conflict, we might as well do the same for `BTreeMap::append`. This also means that some of the code in `append.rs` can be removed; `bulk_push()` however is used by `bulk_build_from_sorted_iterator()`, which is used by the `From`/`FromIterator` trait impl on `BTreeMap`. Feels like we should rename the file or place the `bulk_push()` in an existing file.
The same additional optimization consideration that `BTreeMap::merge` has is also applied to `BTreeMap::append`.
r? @Mark-Simulacrum since Mark has seen the `BTreeMap::merge` code already (only diff is the `Ordering::Equal` case and now one of the test assertions on a panic case has the correct value now).
refactor RangeFromIter overflow-checks impl
Crates with different overflow-checks settings accessing the same RangeFromIter resulted in incorrect values being yielded
Fixesrust-lang/rust#154124
r? @tgross35
`std`: include `dlmalloc` for all non-wasi Wasm targets
Currently, building std for a custom Wasm target with an OS other than `unknown` will fail, because `sys/alloc/mod.rs` will attempt to use `sys/alloc/wasm.rs`, the dlmalloc-based allocator used on `wasm32-unknown-unknown`. However, currently dlmalloc is only pulled in when `target_os = "unknown"`.
Instead, we should make `Cargo.toml` and `alloc/mod.rs` match: either
- disable `wasm.rs` in `alloc/mod.rs` where `not(target_os = "unknown")`, or
- pull in `dlmalloc` for all Wasm targets with `target_family = "wasm32"` that aren't covered by the [upper branches of `alloc/mod.rs`](https://github.com/rust-lang/rust/blob/main/library/std/src/sys/alloc/mod.rs#L72-L100).
This PR takes the latter approach, because it allows more code to compile without a custom allocator.
We've already stabilized float operations in const,
which means we've already accepted that a `const fn`
might behave differently in consteval vs at run time.
don't suggest non-deriveable traits for unions
Fixesrust-lang/rust#137587
Before, the compiler suggested adding `#[derive(Debug)]` (other traits too) for unions,
which is misleading because some traits can't be automatically derived.
Only traits that are still suggested are Copy and Clone.
I noticed the error label changed after removing the suggestion. I hope this isn't a big deal, but let me know if that's an issue.
original example:
```rs
union Union {
member: usize,
}
impl PartialEq<u8> for Union {
fn eq(&self, rhs: &u8) -> bool {
unsafe { self.member == (*rhs).into() }
}
}
fn main() {
assert_eq!(Union { member: 0 }, 0);
}
```
before:
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Debug` is not implemented for `Union`
|
= note: add `#[derive(Debug)]` to `Union` or manually `impl Debug for Union`
= note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `Union` with `#[derive(Debug)]`
|
2 + #[derive(Debug)]
3 | union Union {
|
```
after (the message doesn't suggest adding #[derive(Debug)] to unions)
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Debug` is not implemented for `Union`
--> src\main.rs:2:1
|
2 | union Union {
| ^^^^^^^^^^^
= note: manually `impl Debug for Union`
```
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".
vec::Drain::fill: avoid reference to uninitialized memory
`range_slice` points to memory that is not initialized (e.g. it might be dropped `Box`/`String`). Let's avoid that and instead use an index-based loop.
coretests: Expand ieee754 parsing and printing tests to f16
Use `float_test!` to cover all types, with a note about f128 missing the traits. Also includes some minor reorganization.
two smaller feature cleanups
Remove an unneeded feature gate for a private macro and sort the used features correctly by whether they are language or library features.
Derive Macro Eq: link to more detailed documentation
Match the other derive macros in the module (Ord, PartialEq, PartialOrd) by linking to the section in the trait documentation about how the derive macro works.
Add is_disconnected functions to mpsc and mpmc channels
Add `is_disconnected()` functions to the `Sender` and `Receiver` of both `mpmc` an `mpsc` channels.
```rust
std::sync::mpmc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpmc::Receiver<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Receiver<T>::is_disconnected(&self) -> bool
```
The `mpsc` methods are locked behind the `mpsc_is_disconnected` feature gate, which has no tracking issue yet.
ACP: https://github.com/rust-lang/libs-team/issues/748
Tracking issue: https://github.com/rust-lang/rust/issues/153668
Split the `dec2flt::RawFloat` trait for easier reuse
`RawFloat` is an internal trait with quite a few useful float properties. It currently resides in the `dec2flt` module but is also used in parsing, and would be nice to reuse other places. Unfortunately it cannot be implemented on `f128` because of limitations with how the parsing API is implemented (mantissa must fit into a u64).
To make the trait easier to work with, split it into the following:
* `Float`: Anything that is reasonably applicable to all floating point types.
* `FloatExt`: Items that should be part of `Float` but don't work for all float types. This will eventually be merged back into `Float` once it can be implemented on f128.
* `Lemire`: Items that are specific to the Lemire dec2flt algorithm.
These traits are then moved to places that make sense.
Builds on top of https://github.com/rust-lang/rust/pull/151900
Optimize 128-bit integer formatting
The compiler is unaware of the restricted range of the input, so it is unable to optimize out the final division and modulus. By doing this manually, we get a nontrivial performance gain.
r? @dtolnay
(copied from https://github.com/dtolnay/itoa/pull/68)
Add `Wake` diagnostic item for `alloc::task::Wake`
The symbol will be defined in Clippy, as Clippy will be the sole user of the diagnostic item so far.
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.
Add missing `track_caller` to overflowing trait methods
Fixesrust-lang/rust#152599 by adding `#[track_caller]` to arithmetic trait methods (`Neg`, `Shl`, `ShlAssign`, `Shr` and `ShrAssign`) so overflow panics report the correct call site instead of the trait definition.
The compiler is unaware of the restricted range of the input, so it is
unable to optimize out the final division and modulus. By doing this
manually, we get a nontrivial performance gain.
Jonathan Brouwer