This caused several performance regressions because of existing code
which uses `Read::read` and therefore requires full buffer
initialization. This is particularly a problem when the same buffer is
re-used for multiple read calls since this means it needs to be fully
re-initialized each time.
There is still some benefit to landing the API changes, but we will have
to add private APIs so that the existing infrastructure can
track and avoid redundant initialization.
(cherry picked from commit 4b07875505)
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#148662 (alloc: Document panics when allocations will exceed max)
- rust-lang/rust#148811 (core docs: rewrite `panic::Location::caller` with visual line/column numbers)
- rust-lang/rust#149101 (Improve mutable-binding suggestion to include name)
- rust-lang/rust#149477 (float::maximum/minimum: make docs more streamlined)
- rust-lang/rust#149547 (library: Rename `IterRange*` to `Range*Iter`)
- rust-lang/rust#149548 (Generate delegation error body when delegation is not resolved)
- rust-lang/rust#149630 (Check identifiers defined in macros when suggesting identifiers hidden by hygiene)
- rust-lang/rust#149647 (Add regression test for 141845)
- rust-lang/rust#149661 (Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.)
- rust-lang/rust#149666 (Add perma-unstable `--print=backend-has-zstd` for use by compiletest)
- rust-lang/rust#149671 (interpret: test SNaN handling of float min/max and update comments)
r? `@ghost`
`@rustbot` modify labels: rollup
interpret: test SNaN handling of float min/max and update comments
Also see https://github.com/rust-lang/rust/pull/149563.
I also renamed these enum variants so they are not almost identical.
Add perma-unstable `--print=backend-has-zstd` for use by compiletest
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler.
---
Originally I was intending for this to be a `--print=debuginfo-compression` flag that would print out a list of values supported by `-Zdebuginfo-compression=`. I got that working locally, but it was more complex than I was happy with (in both rustc and compiletest), so I decided to cut scope and instead add a very narrow perma-unstable print request instead.
There is always a circularity hazard whenever we ask the compiler-under-test for information about how to test it. But in this case, the underlying compiler code is fairly simple, whereas the previous heuristics were inherently messy and unreliable anyway.
Fix for LLVM22 making lowering decisions dependent on RuntimeLibraryInfo.
LLVM added codegen decision making based on RuntimeLibraryInfo. Mirror the change in Rust's codegen.
LLVM reference commit:
04c81a9973.
Add regression test for 141845
close: rust-lang/rust#141845
I saw the `tests/ui/associated-inherent-types` directory, but I felt the current location was a better fit.
Check identifiers defined in macros when suggesting identifiers hidden by hygiene
Fixrust-lang/rust#149604
r? `@JonathanBrouwer` (Since you reviewed the other one related to this)
Generate delegation error body when delegation is not resolved
This PR relates to the delegation feature rust-lang/rust#118212, it fixesrust-lang/rust#144594 ICE.
r? `@petrochenkov`
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
alloc: Document panics when allocations will exceed max
Document panics in `String` and `Vec` due to capacity overflowing `isize::MAX`. Correct outdated claims of `usize::MAX` limit.
Fixes https://github.com/rust-lang/rust/issues/148598.
Ping `@lolbinarycat`
misc coercion cleanups and handle safety correctly
r? lcnr
### "remove normalize call"
Fixesrust-lang/rust#132765
If the normalization fails we would sometimes get a `TypeError` containing inference variables created inside of the probe used by coercion. These would then get leaked out causing ICEs in diagnostics logic
### "leak check and lub for closure<->closure coerce-lubs of same defids"
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/233
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
return |x| x + 1
}
```
the `|x| x + 1` expr has a type of `Closure(?31t)` which we wind up inferring the RPIT to. The `CoerceMany` `ret_coercion` for the whole `peculiar` typeck has an expected type of `RPIT` (unnormalized). When we type check the `return |x| x + 1` expr we go from the never type to `Closure(?31t)` which then participates in the `ret_coercion` giving us a `coerce-lub(RPIT, Closure(?31t))`.
Normalizing `RPIT` gives us some `Closure(?50t)` where `?31t` and `?50t` have been unified with `?31t` as the root var. `resolve_vars_if_possible` doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a `fn` ptr. cc rust-lang/rust#147193 which also fixes this
New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3
### FCP worthy stuffy
there are some other FCP worthy things but they're in my FCP comment which also contains some analysis of the breaking nature of the previously listed changes in this PR: https://github.com/rust-lang/rust/pull/148602#issuecomment-3503497467
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built
without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether
the compiler's LLVM was built with zstd support. But the compiler itself
already knows whether LLVM has zstd or not, so it's easier for compiletest to
just ask the compiler.
Update cargo submodule
9 commits in bd979347d814dfe03bba124165dbce9554d0b4d8..2c283a9a5c5968eeb9a8f12313f04feb1ff8dfac
2025-12-02 16:03:50 +0000 to 2025-12-04 16:47:28 +0000
- fix(publish): Move `.crate` out of final artifact location (rust-lang/cargo#15915)
- Remove legacy tmpdir support (rust-lang/cargo#16342)
- Run clippy CI on more targets (rust-lang/cargo#16340)
- feat: support for rustdoc mergeable cross-crate info (rust-lang/cargo#16309)
- fix(timings): unlocked -> unblocked (rust-lang/cargo#16337)
- fix(layout): Put examples in their unit dir in new layout (rust-lang/cargo#16335)
- fix(frontmatter): Restrict code fence length (rust-lang/cargo#16334)
- Update resolver.md: fix compile errors in pseudocode (rust-lang/cargo#16333)
- fix(fingerprint): clean doc dirs for only requested targets (rust-lang/cargo#16331)
This is best being merged before beta cutoff because rust-lang/cargo#16337 is a nightly regression.
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`
Move attribute safety checking to attribute parsing
This PR moves attribute safety checking to be done during attribute parsing. The `cfg` and `cfg_attr` attribute no longer need special-cased safety checking, yay!
This PR is a part 1 of 2, in the second part I'd like to define attribute safety in the attribute parsers rather than getting the information from BUILTIN_ATTRIBUTE_MAP, but to keep PRs reviewable lets do that separately.
Fixes https://github.com/rust-lang/rust/issues/148453 by reordering the diagnostics. The "cannot find attribute" diagnostic now appears first, but both diagnostics still appear.
r? `@jdonszelmann`
Tidying up UI tests [6/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
removed directory `tests/ui/trait-objects`, `tests/ui/for`, `tests/ui/warnings`
`trait-objects` -> `traits/object`
`for` -> `for-loop-while` (except `for/issue-20605.rs` test. this relocated to `traits/dyn-iterator-deref-in-for-loop.rs`)
`warnings` -> `resolve`, `entry-point`
r? Kivooeo
Recover on misspelled item keyword
the title says everything. first commit adds a test that shows how current `main` behaves on misspelled item keyword. second commit adds the recovery, which allows to emit many more errors.
Implement benchmarks for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: https://github.com/rust-lang/rust/issues/149069
Accepted ACP: https://github.com/rust-lang/libs-team/issues/695#issuecomment-3549284861
For each method, there are three benchmarks, which differ in that the mask (second) argument is one of:
- constant at compile time
- runtime value but invariant for the measured loop
- different for each call
Sample output
```text
num::int_bits::u32::constant::gather_bits 555.82ns/iter +/- 22.41
num::int_bits::u32::constant::scatter_bits 545.45ns/iter +/- 124.26
num::int_bits::u32::invariant::gather_bits 8178.86ns/iter +/- 217.37
num::int_bits::u32::invariant::scatter_bits 7135.95ns/iter +/- 214.51
num::int_bits::u32::variable::gather_bits 10539.29ns/iter +/- 198.90
num::int_bits::u32::variable::scatter_bits 9671.26ns/iter +/- 254.88
```
(and similarly for the other `uN` types)
Allow PowerPC spe_acc as clobber-only register
This register is only supported on the *powerpc*spe targets. It is only recognized by LLVM. gcc does not accept this as a clobber, nor does it support these targets.
This is a volatile register, thus it is included with clobber_abi.
r? `@Amanieu`
r? `@antoyo`
