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`.
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.
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] {}
| +++++ ++++++++++++
```
Reduce flakyness for `tests/rustdoc-gui/notable-trait.goml`
Fixes https://github.com/rust-lang/rust/issues/151006 (hopefully).
Instead of asserting right away, it waits for the element count to be the one expected.
r? @jieyouxu
ui: add regression test for macro resolution ICE (issue #150711)
Added a new test in `test/ui/resolve` for a macro
resolution scenario that previously caused an ICE.
Files added:
- `tests/ui/resolve/decl-macro-use-no-ice.rs`
- `tests/ui/resolve/decl-macro-use-no-ice.stderr`
Fixesrust-lang/rust#150711
r? @matthiaskrgr
r? @petrochenkov
Support arrays in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting arrays `[T; N]` through type reflection. It does so by adding `TypeKind::Array` and the `Array` struct:
```rust
pub struct Array {
pub element_ty: TypeId,
pub len: usize,
}
```
This can be used to inspect arrays like so:
```rust
match const { Type::of::<[u16; 4]>() }.kind {
TypeKind::Array(array) => {
assert_eq!(array.element_ty, TypeId::of::<u16>());
assert_eq!(array.len, 4);
}
_ => unreachable!(),
}
```
r? @oli-obk
Make `Type::of` support unsized types
Tracking issue: rust-lang/rust#146922Fixesrust-lang/rust#151018
`Type::of` is a utility function for getting type reflection information, and internally just calls `TypeId::of::<T>().info()`. `Type::of` does not support unsized types like `str` and `[u8]` because it is missing a `?Sized` bound. I believe this is an oversight rather than an intentional decision, as `TypeId::of` _does_ support unsized types and `Type::size` is an `Option` to support types without sizes.
This PR adds a `?Sized` bound to `Type::of` and extends the `dump.rs` test to ensure unsized types work in the future.
r? @oli-obk
Regression test for type params on eii
Somewhere along the line I fixed this one with my other PRs. This just adds the regression tests
Closesrust-lang/rust#149983
Make `--print=check-cfg` output compatible `--check-cfg` arguments
This PR changes significantly the output of the unstable `--print=check-cfg` option.
Specifically it removes the ad-hoc resemblance with `--print=cfg` in order to output a simplified but still compatible `--check-cfg` arguments.
The goal is to future proof the output of `--print=check-cfg` like `--check-cfg` is, and the best way to do that is to use it's syntax.
This is particularly relevant for [RFC3905](https://github.com/rust-lang/rfcs/pull/3905) which wants to introduce a new predicate: `version(...)`.
