Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#151166 (fix: Do not delay E0107 when there exists an assoc ty with the same name)
- rust-lang/rust#151185 (Disable `dump-ice-to-disk` on `i686-pc-windows-msvc`)
r? @ghost
Disable `dump-ice-to-disk` on `i686-pc-windows-msvc`
Sometimes the middle frames of the ICE backtrace becomes `<unknown>` on `i686-pc-windows-msvc` which then makes this test flaky. Noticed in https://github.com/rust-lang/rust/pull/150925#issuecomment-3754504924.
Originally expanded in rust-lang/rust#142563 to see if it's still flaky for other `*-windows-*` targets, unfortunately the answer is yes for `i686-pc-windows-msvc` as well.
r? @dianqk (or compiler or anyone really)
fix: Do not delay E0107 when there exists an assoc ty with the same name
Fixesrust-lang/rust#148121
When we have the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for String {}
```
we delay `E0107: wrong number of generic args` to suggest moving `T: Default` bound to the impl block's param declaration.
The delay is determined by whether all the missing generic parameters are mentioned by those *wrong* assoc item constraints.
But this delay is wrong when there exist any *correct* assoc item constraints, i.e. when we have an assoc type whose identifier is same with a missing generic parameter like in the following code:
```rust
pub trait Super<X> {
type X;
}
pub trait A {}
impl A for dyn Super<X = ()> {}
```
THIR patterns: Always use type `str` for string-constant-value nodes
Historically, constants and literals of type `&str` have been represented in THIR patterns as `PatKind::Const` nodes with type `&str`.
That's fine for stable Rust, but `feature(deref_patterns)` also created a need to have string literal patterns of type `str` in some cases, which resulted in a number of additional special cases and inconsistencies in typechecking and in HIR-to-THIR-to-MIR lowering of patterns.
We can avoid several of those special cases by having THIR treat string-constant-values as fundamentally being of type `str`, and then using `PatKind::Deref` to represent the additional `&` layer in the common case where it is needed. This allows bare `str` patterns to require very little special treatment.
Existing tests should already do a good job of demonstrating that this implementation change does not affect the stable language.
Stabilise `EULER_GAMMA` and `GOLDEN_RATIO` constants for `f32` and `f64`.
Tracking issue: rust-lang/rust#146939
This PR renames the `EGAMMA` and `PHI` constants to `EULER_GAMMA` and `GOLDEN_RATIO` – respectively – and stabilises them under these names for `f32` and `f64`:
```rust
// core::f16::consts
pub const GOLDEN_RATIO: f16;
pub const EULER_GAMMA: f16;
// core::f32::consts
pub const GOLDEN_RATIO: f32;
pub const EULER_GAMMA: f32;
// core::f64::consts
pub const GOLDEN_RATIO: f64;
pub const EULER_GAMMA: f64;
// core::f128::consts
pub const GOLDEN_RATIO: f128;
pub const EULER_GAMMA: f128;
```
The feature gate for the stabilised items is also changed to `euler_gamma_golden_ratio`.
Tidying up `tests/ui/issues` 15 tests [8/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
There are some tests named {xxx}-2, which are meant to be merged with {xxx}.
r? Kivooeo
Unify and deduplicate From<T> float tests
cc rust-lang/rust#141726
Unify the From<bool> tests from f16.rs and f128.rs into a single float_test! in mod.rs.
Add amdgpu_dispatch_ptr intrinsic
There is an ongoing discussion in rust-lang/rust#150452 about using address spaces from the Rust language in some way.
As that discussion will likely not conclude soon, this PR adds one rustc_intrinsic with an addrspacecast to unblock getting basic information like launch and workgroup size and make it possible to implement something like `core::gpu`.
Add a rustc intrinsic `amdgpu_dispatch_ptr` to access the kernel dispatch packet on amdgpu.
The HSA kernel dispatch packet contains important information like the launch size and workgroup size.
The Rust intrinsic lowers to the `llvm.amdgcn.dispatch.ptr` LLVM intrinsic, which returns a `ptr addrspace(4)`, plus an addrspacecast to `addrspace(0)`, so it can be returned as a Rust reference.
The returned pointer/reference is valid for the whole program lifetime, and is therefore `'static`.
The return type of the intrinsic (`&'static ()`) does not mention the struct so that rustc does not need to know the exact struct type. An alternative would be to define the struct as lang item or add a generic argument to the function.
Is this ok or is there a better way (also, should it return a pointer instead of a reference)?
Short version:
```rust
#[cfg(target_arch = "amdgpu")]
pub fn amdgpu_dispatch_ptr() -> *const ();
```
Tracking issue: rust-lang/rust#135024
Only use SSA locals in SimplifyComparisonIntegral
Fixes https://github.com/rust-lang/rust/issues/150904.
The place may be modified from the comparison statement to the switchInt terminator.
Best reviewed commit by commit.
merge privacy/privacy-sanity-2 with privacy/privacy-sanity.rs
Add comment to generics/type-args-on-module-in-bound.rs
Add comment to array-slice-vec/closure-in-array-eln.rs
Add comment to array-slice-vec/return-in-array-len.rs
Merge for-loop-while/break-outside-loop-2.rs with
for-loop-while/break-outside-loop.rs
Add comment to macros/column-macro-collision.rs
Add comment to privacy/private-extern-fn-visibility.rs
Add comment to mismatched_types/vec-hashset-type-mismatch.rs
Merge std-sync-right-kind-impls-2.rs with std-sync-right-kind-impls.rs
Add comment to array-slice-vec/slice-of-multi-ref.rs
Add comment to mismatched_types\vec-hashset-type-mismatch.rs
Add comment to derives/derive-hygiene-struct-builder.rs
Add comment to label/undeclared-label-span.rs
Add comment to label\undeclared-label-span.rs
Add comment to mismatched_types/array-repeat-unit-struct.rs
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#150846 (include `HirId`s directly in the THIR, not wrapped in `LintLevel`s)
- rust-lang/rust#150979 (Avoid ICEs after bad patterns, for the other syntactic variants)
- rust-lang/rust#151103 (mir_build: Simplify length-determination and indexing for array/slice patterns)
- rust-lang/rust#151130 (resolve: Downgrade `ambiguous_glob_imports` to warn-by-default)
r? @ghost
mir_build: Simplify length-determination and indexing for array/slice patterns
The existing length-determination code in `prefix_slice_suffix` has ended up overly complicated, partly because it doesn't know in advance whether the pattern is supposed to be an array pattern or a slice pattern.
Pulling most of that step out into the `PatKind::Array` arm makes the whole thing a bit nicer overall.
There should (hopefully) be no change to compiler output. The biggest “functional” change is that we now discard the subpatterns of an array pattern of unknowable length, instead of treating it as a slice pattern. I'm not aware of any way for this to make an observable difference, and it can only occur when compilation is already doomed to fail.
Avoid ICEs after bad patterns, for the other syntactic variants
This PR introduces changes equivalent to the ones in rust-lang/rust#126320, but also for struct and tuple patterns, instead of tuple struct patterns only.
Fixesrust-lang/rust#150507.
include `HirId`s directly in the THIR, not wrapped in `LintLevel`s
Occurrences of `LintLevel` in the THIR were always `LintLevel::Explicit`, containing a `HirId`, so we don't need to make it possible to put `LintLevel::Inherited` there. Removing the unused case where `HirId`s aren't present in the THIR slightly simplifies diagnostics/lints/tools that want to map from the THIR back to the HIR, e.g. rust-lang/rust#145569.
Since `LintLevel` is no longer present in the THIR, I've moved it in the second commit to live in `rustc_mir_build`; that's where it's actually used. I'm not sure exactly where exactly it should live there, but I put it in the `builder::scope` module since it's used by `Builder::in_scope` for determining when to introduce source scopes.
r? lcnr as the reviewer of rust-lang/rust#145569, since this was discussed there
Change `bors build finished` job to `publish toolstate`
Due to recent advancements in merge queue bot technology, we no longer need this job. We still use a simpler job to publish the toolstate on `auto` builds though.
Should be merged once we get rid of homu.
This reverts PR <https://github.com/rust-lang/rust/pull/130998> because
the added test seems to be flaky / non-deterministic, and has been
failing in unrelated PRs during merge CI.
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
