replace addr_of_mut with &raw mut in maybeuninit docs
In the docs for `addr_of_mut` it says that the macro is "soft-deprecated" so maybe the std docs should stop recommending it.
I searched for other places where this is used, but didn't find any in public stable documentation.
Constify `DropGuard::dismiss` and trait impls
Feature: `drop_guard` (rust-lang/rust#144426), `const_convert` (rust-lang/rust#143773), `const_drop_guard` (no tracking issue yet)
Constifies `DropGuard::dismiss` and trait impls.
I reused `const_convert` (rust-lang/rust#143773) for the `Deref*` impls.
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
Use `PointeeSized` bound for `TrivialClone` impls
These `TrivialClone` impls previously had `?Sized` bounds, which are different from the `PointeeSized` bounds on the corresponding `Clone` and `Copy` impls. So, I've changed the `?Sized` bounds into `PointeeSized` bounds.
This mistake was made presumably because the `TrivialClone` PR (https://github.com/rust-lang/rust/pull/135634) was opened in Jan 2025, but merged in Nov 2025. During that time, the sized hierachy PR (https://github.com/rust-lang/rust/pull/137944) was opened in Mar 2025, and merged in Jun 2025. The `TrivialClone` PR was not updated to account for the sized hierachy changes.
r? `@joboet`
These `TrivialClone` impls previously had `?Sized` bounds, which are
different from the `PointeeSized` bounds on the corresponding
`Clone` and `Copy` impls. So, I've changed the `?Sized` bounds into
`PointeeSized` bounds.
This mistake was made presumably because the `TrivialClone` PR
(https://github.com/rust-lang/rust/pull/135634) was opened in Jan 2025,
but merged in Nov 2025. During that time, the sized hierachy PR
(https://github.com/rust-lang/rust/pull/137944) was opened in Mar 2025,
and merged in Jun 2025. The `TrivialClone` PR was not updated to account
for the sized hierachy changes.
Add `ilog10` result range hints
This PR adds hints that the return value of `T::ilog10` will never exceed `T::MAX.ilog10()`.
This works because `ilog10` is a monotonically nondecreasing function, the maximum return value is reached at the max input value.
Improve error message for std integer clamp() if min > max
For rust-lang/rust#142309: change the error message for `Ord::clamp()` for std integer types if min > max to be more useful.
Message is now `min > max. min = {min:?}, max = {max:?}`
Also add `#[track_caller]` to `clamp()`
Assume the returned value in `.filter(…).count()`
Similar to how this helps in `slice::Iter::position`, LLVM sometimes loses track of how high this can get, so for `TrustedLen` iterators tell it what the upper bound is.
add Option::into_flat_iter
Tracking issue: rust-lang/rust#148441
I only implemented `into_flat_iter` in this PR, but I'd be happy to add `flat_iter` / `flat_iter_mut` (equivalent to calling `as_ref` / `as_mut` first) if those are desired. See rust-lang/libs-team#626 for context.
Implement `Allocator` for `&mut A` where `A: Allocator + ?Sized`
This is a breaking change to the unstable `allocator_api` feature. Tracking issue rust-lang/rust#32838.
It implements the accepted api change proposal from rust-lang/libs-team#508.
The code for the blanket implementation is the same as the one for `&A`, just with the `mut` added.
f*::min/max: fix comparing with libm and IEEE operations
What we document actually doesn't match what libm does any more, libm got "fixed"/changed in https://sourceware.org/bugzilla/show_bug.cgi?id=20947. So better remove the remark. Instead, explicitly call out that this is a mix of `minNum` and `minimumNumber`.
Also fix the intrinsics which incorrectly claimed to be like `minNum`, but their intended SNaN behavior is actually different from that.
r? `@tgross35`
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
library: Rename `IterRange*` to `Range*Iter`
There is a weak convention in the ecosystem that `IterFoos` is an iterator yielding items of type `Foo` (e.g. `bitflags` `IterNames`, `hashbrown` `IterBuckets`), while `FooIter` is an iterator over `Foo` from an `.iter()` or `.into_iter()` method (e.g. `memchr` `OneIter`, `regex` `SetMatchesIter`). Rename `IterRange`, `IterRangeInclusive`, and `IterRangeFrom` to `RangeIter`, `RangeInclusiveIter`, and `RangeInclusiveIter` to match this.
Tracking issue: https://github.com/rust-lang/rust/issues/125687 (`new_range_api`)
float::maximum/minimum: make docs more streamlined
This does with `maximum`/`minimum` what https://github.com/rust-lang/rust/pull/149475 did with `max`/`min`: first a self-contained description of the semantics, then comparing with other operations. It also makes the wording consistent with those other functions. Previously we had some of the semantics below the examples for some reason, and we repeated "If one of the arguments is NaN, then NaN is returned"; that has been streamlined as well.
r? `@tgross35`
core docs: rewrite `panic::Location::caller` with visual line/column numbers
no tracking issue
hey, this is my first PR on rust-lang/rust, so hopefully everything goes well.
i noticed the documentation for `core::panic::Location::caller` was kind of unintelligible (and maybe even wrong due to standalone_crate) and filled with magic numbers, so i provided line and column numbers as a visual guidance as to how it should be used.
edit: uh oh, looks like i pushed changes from random commits unrelated to me, what's going on?
edit2: reverted the unintended changes by this pr
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#147224 (Emscripten: Turn wasm-eh on by default)
- rust-lang/rust#149405 (Recover on misspelled item keyword)
- rust-lang/rust#149443 (Tidying up UI tests [6/N])
- rust-lang/rust#149524 (Move attribute safety checking to attribute parsing)
- rust-lang/rust#149593 (powf, powi: point out SNaN non-determinism)
- rust-lang/rust#149605 (Use branch name instead of HEAD when unshallowing)
- rust-lang/rust#149612 (Apply the `bors` environment also to the `outcome` job)
- rust-lang/rust#149623 (Don't require a normal tool build of clippy/rustfmt when running their test steps)
- rust-lang/rust#149627 (Point to the item that is incorrectly annotated with `#[diagnostic::on_const]`)
r? `@ghost`
`@rustbot` modify labels: rollup
powf, powi: point out SNaN non-determinism
The non-determinism has two sources:
- LLVM reserves the right to treat signaling NaNs as-if they were quiet, so it may fold `powf(x, 0)` to `1` even if `x` might be a signaling NaN.
- Some libm `pow` implementations (e.g. the one in musl) don't implement the signaling NaN special-case. See https://rust.godbolt.org/z/chsbv5v4d.
Cc `@tgross35` `@Amanieu`
Fix std::mem::drop rustdoc misleading statement
This is a bit misleading, we were discussing this with our Rust team and some people could think that the compiler does some special magic for this specific function and that's not true or well the compiler does something special but for every function.
The reality according to my understanding is that this is a normal function that takes ownership of the given value and as with every other function mir building injects Drop Terminators , drop elaboration refines this and then we would insert the corresponding drop glue, then potentially calling Drop::drop.
Not sure if it would be best to remove the sentence as this PR does or explaining something along the lines of the previous text.
Jonathan Brouwer