Rename `rust.use-lld` to `rust.bootstrap-override-lld` in INSTALL.md
I was trying to follow the example configure command in `INSTALL.md` and found that it gives error after `rust.use-lld` is renamed by 852aa20c90.
Avoid serde dependency in build_helper when not necessary
Run-make-support doesn't need the metrics code to be pulled in ever. And bootstrap only needs it in CI where build metrics support is enabled.
Recover parse gracefully from `<const N>`
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
r? @fmease
Follow up to rust-lang/rust#151077. Fixrust-lang/rust#84327.
fix: WASI threading regression by disabling pthread usage
PR rust-lang/rust#147572 changed WASI to use the Unix threading implementation, but WASI does not support threading. When the Unix code tries to call pthread_create, it fails with EAGAIN, causing libraries like rayon to panic when trying to initialize their global thread pool.
The old wasip1/wasip2 implementations:
- wasip1: Threading conditionally available with atomics (experimental)
- wasip2: Threading unconditionally unsupported
This fix restores that behavior by disabling pthread-based threading for all WASI targets:
1. Guard the pthread-based Thread implementation with #[cfg(not(target_os = "wasi"))]
2. Provide an unsupported stub (Thread(!)) for WASI
3. Return Err(io::Error::UNSUPPORTED_PLATFORM) when Thread::new is called
Fixes the regression where rayon-based code (e.g., lopdf in PDF handling) panicked on WASI after nightly-2025-12-10.
Before fix:
pthread_create returns EAGAIN (error code 6)
ThreadPoolBuildError { kind: IOError(Os { code: 6,
kind: WouldBlock, message: "Resource temporarily unavailable" }) }
After fix:
Thread::new returns Err(io::Error::UNSUPPORTED_PLATFORM)
Libraries can gracefully handle the lack of threading support
r? @alexcrichton
Disallow eii in statement position
With how v2 macros resolve, and the name resolution of `super` works, I realized with @WaffleLapkin that there's actually no way to consistently expand EIIs in statement position.
r? @WaffleLapkin
rustc_target: Remove unused Arch::PowerPC64LE
This variant has been added in https://github.com/rust-lang/rust/pull/147645, but actually unused since target_arch for powerpc64le- targets is "powerpc64". (The difference between powerpc64- and powerpc64le- targets is identified by target_endian.)
Note: This is an internal cleanup and does NOT remove `powerpc64le-*` targets.
Remove `FeedConstTy` and provide ty when lowering const arg
r? @BoxyUwU
edit: BoxyUwU
`FeedConstTy` currently only provides the expected type of a const argument *sometimes* (e.g. previously array lengths did not do this). This causes problems with mGCA's directly represented const arguments which always need to know their expected type.
cleanup: remove borrowck handling for inline const patterns
rust-lang/rust#120390 added borrow-checking for inline const patterns; a type annotation was added to inline const patterns in the THIR to remember the `DefId` and args of the constants so they could be checked and constraints could be propagated to their parents. As of rust-lang/rust#138499 though, inline const patterns can't be borrow-checked due to a query cycle, and as of rust-lang/rust#149667, the type/`DefId`/args annotations on inline const patterns have been removed, so the borrowck code for them seems unused; this PR removes it.
In a hypothetical future where borrowck doesn't depend on exhaustiveness checking so `inline_const_pat` can be reinstated, I imagine we also won't be evaluating inline const patterns before borrowck. As such, we might be able to reuse the existing code for normal unevaluated inline const operands in [`TypeChecker::visit_operand`](32fe406b5e/compiler/rustc_borrowck/src/type_check/mod.rs (L1720-L1749)) (or at least we shouldn't need to encode inline const patterns' `DefId` and args in user type annotations if they appear directly in the MIR).
r? lcnr
Don't try to recover keyword as non-keyword identifier
Fixesrust-lang/rust#149692.
On beta after rust-lang/rust#146978, we ICE on
```rs
macro_rules! m {
($id:item()) => {}
}
m!(Self());
```
where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails.
I suspect rust-lang/rust#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like
```rs
error: expected identifier, found keyword `Self`
--> src/lib.rs:5:4
|
5 | m!(Self());
| ^^^^ expected identifier, found keyword
error: missing `fn` or `struct` for function or struct definition
--> src/lib.rs:5:4
|
2 | ($id:item()) => {}
| -------- while parsing argument for this `item` macro fragment
...
5 | m!(Self());
| ^^^^
|
help: if you meant to call a macro, try
|
5 | m!(Self!());
| +
```
I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
rustdoc: Fix intra-doc link bugs involving type aliases and associated items
This PR:
- Add support for linking to fields of variants behind a type alias.
- Correctly resolve links to fields and variants behind a type alias to the alias's version of the docs.
- Refactor some intra-doc links code to make it simpler.
- Add tests for the status quo of linking to associated items behind aliases.
Future steps:
- Nail down the rules of when inherent and trait impls are inlined into an alias's docs, and when impls on the alias appear for the aliased type.
- Adjust the resolutions of intra-doc links, through aliases, to associated items based on these rules.
r? @GuillaumeGomez
Add a context-consistency check before emitting redundant generic-argument suggestions
Fixesrust-lang/rust#149559
Add a context-consistency check before emitting redundant generic-argument suggestions. If the redundant argument spans come from mixed hygiene contexts (e.g., macro definition + macro callsite), we skip the suggestion to avoid malformed `shrink_to_hi().to(...)` spans and potential ICEs.
When a const param doesn't have a `: Type`, recover the parser state and provide a structured suggestion. This not only provides guidance on what was missing, but it also makes subsuequent errors to be emitted that would otherwise be silenced.
```
error: expected `:`, found `>`
--> $DIR/incorrect-const-param.rs:26:16
|
LL | impl<T, const N> From<[T; N]> for VecWrapper<T>
| ^ expected `:`
|
help: you might have meant to write the type of the const parameter here
|
LL | impl<T, const N: /* Type */> From<[T; N]> for VecWrapper<T>
| ++++++++++++
```
The opposite ordering was a consistent source of confusion during debuggingю
`report_conflict` actually used an incorrect order due to similar confusion.
Recent changes made WASI targets use the Unix threading implementation, but
WASI does not support threading. When the Unix code tries to call
pthread_create, it fails with EAGAIN, causing libraries like rayon to
panic when trying to initialize their global thread pool.
This fix adds an early return in Thread::new() that checks for WASI and
returns UNSUPPORTED_PLATFORM. This approach:
- Continues using most of the unix.rs code path (less invasive)
- Only requires a small cfg check at the start of Thread::new()
- Can be easily removed once wasi-sdk is updated with the proper fix
The real fix is being tracked in `WebAssembly/wasi-libc#716` which will
change the error code returned by pthread_create to properly indicate
unsupported operations. Once that propagates to wasi-sdk, this workaround
can be removed.
Fixes the regression where rayon-based code (e.g., lopdf in PDF handling)
panicked on WASI after nightly-2025-12-10.
Before fix:
pthread_create returns EAGAIN (error code 6)
ThreadPoolBuildError { kind: IOError(Os { code: 6,
kind: WouldBlock, message: "Resource temporarily unavailable" }) }
After fix:
Thread::new returns Err(io::Error::UNSUPPORTED_PLATFORM)
Libraries can gracefully handle the lack of threading support
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#149408 (refactor: remove Ord bound from BinaryHeap::new etc)
- rust-lang/rust#150406 (Change some `matches!(.., .. if ..)` with let-chains)
- rust-lang/rust#150723 (std: move `errno` and related functions into `sys::io`)
- rust-lang/rust#150877 (resolve: Refactor away the side table `decl_parent_modules`)
- rust-lang/rust#150902 (Update to_uppercase docs to avoid ß->SS example)
- rust-lang/rust#151034 (std: Change UEFI env vars to volatile storage)
- rust-lang/rust#151036 (Better handle when trying to iterate on a `Range` of a type that isn't `Step`)
- rust-lang/rust#151067 (Avoid should-fail in two ui tests and a codegen-llvm test)
- rust-lang/rust#151072 (also handle ENOTTY ioctl errors when checking pidfd -> pid support)
- rust-lang/rust#151077 (Recognize potential `impl<const N: usize>` to `impl<N>` mistake)
- rust-lang/rust#151096 (Remove `Deref`/`DerefMut` impl for `Providers`.)
Failed merges:
- rust-lang/rust#150939 (resolve: Relax some asserts in glob overwriting and add tests)
r? @ghost
Remove `Deref`/`DerefMut` impl for `Providers`.
It's described as a "backwards compatibility hack to keep the diff small". Removing it requires only a modest amount of churn, and the resulting code is clearer without the invisible derefs.
r? @oli-obk
Recognize potential `impl<const N: usize>` to `impl<N>` mistake
When encountering code like `impl<N> Bar<N> for [u8; N]`, suggest `impl<const N: Type> Bar<N> for [u8; N]` as a possibility.
```
error[E0423]: expected value, found type parameter `T`
--> $DIR/issue-69654.rs:5:25
|
LL | impl<T> Bar<T> for [u8; T] {}
| - ^ not a value
| |
| found this type parameter
|
help: you might have meant to write a const parameter here
|
LL | impl<const T: Type> Bar<T> for [u8; T] {}
| +++++ ++++++
```
Addresses "case 3" from rust-lang/rust#84327.
Avoid should-fail in two ui tests and a codegen-llvm test
`should-fail` is only meant for testing the compiletest framework itself. It checks that the test runner itself panicked.
With this there are still a bunch of rustdoc-html tests that use it due to this test suite not supporting anything like `//@ doc-fail`.
Better handle when trying to iterate on a `Range` of a type that isn't `Step`
Mention when a trait bound corresponds to an unstable trait.
Mention `Range` when `Step` bound is unment, and explain that only some std types impl `Iterator` for `Range`.
CC rust-lang/rust#151026
std: Change UEFI env vars to volatile storage
The UEFI variables set by the env vars should be volatile, otherwise they will persist after reboot and use up scarce non-volatile storage.
CC @Ayush1325
Update to_uppercase docs to avoid ß->SS example
Fixesrust-lang/rust#150888
Updates the `to_uppercase` documentation examples to avoid relying on the ß → "SS" mapping and instead uses a stable multi-character case-mapping example ('ffi' → "FFI").
Note: the example uses U+FB03 (LATIN SMALL LIGATURE FFI), not the ASCII string "ffi".
resolve: Refactor away the side table `decl_parent_modules`
Instead keep parent modules in `DeclData` itself.
Follow up to https://github.com/rust-lang/rust/pull/150445.
r? @nnethercote
std: move `errno` and related functions into `sys::io`
Part of rust-lang/rust#117276.
Currently, `errno` and related functions like `decode_error_kind` are split across `sys::pal` and `sys::pal::os`. This PR moves all of them into a new module inside `sys::io`.
