Ship LLVM (`rust-dev`) in fast try builds again
https://github.com/rust-lang/rust/pull/142963 stopped shipping `rust-dev` in fast try builds, which was not actually correct, because if a PR modifies the LLVM submodule, we should provide the prebuilt LLVM for rustc-perf even in a (fast) try build. So why didn't we find out about this earlier? Well, because soon before that PR landed, we started using new bors for try builds, which actually broke bootstrap's git change detection logic, because new bors used a different e-mail address for merge commits.
So the two bugs kind of masked each other out. Recently, we fixed the e-mail address and git change detection with new bors, since it's now also used for auto builds, but that in turn broke fast try builds that modify LLVM (https://github.com/rust-lang/rust/pull/150722#issuecomment-3756545084), because rustc-perf saw that LLVM was modified in the try build, and it (correctly!) tried to download `rust-dev` for the given try build commit, but that was (incorrectly!) missing on CI, due to being skipped.
This PR restored building the `rust-dev` component in fast try builds. In theory, we could use the same git detection logic that bootstrap uses and only do this if LLVM is actually modified in the given commit, but I'd rather do the correct thing here, than introduce additional opportunities for the git detection to desync.
Closing brackets were missing on AdtDef, the field_types list in FruInfo, and InlineAsmExpr, breaking folding in some editors;
Fields were incorrectly (?) indexed in the list for functional update syntax, showing the (implicit, irrelevant) iteration index instead of the field index;
also spurious colon after Pat.
Clean up `rustc_attr_parsing`
Follow-up of rust-lang/rust#150934.
It removes the `Option<>` wrapping for `SharedContext::target` field and completely removed the `target_id` field. Considering this type contains a closure and never updates its `target_id` field, there is no need to keep it around, it can be used directly in the lint emitter.
r? @JonathanBrouwer
Revert `QueryStackFrame` split
PR rust-lang/rust#138672 fixed a query cycle OOM reported in rust-lang/rust#124901. The fix involved delaying computation of some query stack frame elements and was very complex. It involved the addition of two new types, the addition of a generic `I` parameter to eleven(!) other types, a `PhantomData` field, and even required an unsafe transmute of a closure. [This comment](https://github.com/rust-lang/rust/issues/124901#issuecomment-2104852065) had suggested a much simpler fix, but it was ignored. The PR also failed to add a test case.
This PR adds a test case, reverts the complex fix, applies the simpler fix, and does a few other minor cleanups.
r? @oli-obk
remove lcnr from compiler review rotation
Have been feeling somewhat swamped by review and mentoring work and want to focus my review time on involved type system changes. I am very much available to review specific changes, but don't want to be auto-assigned to general compiler changes.
Use `default_field_values` more in `Resolver`
Extend more ways of building `FxHashSet`, `FxHashMap`, `UnordSet`, `UnordMap` and `DisambiguatorState` in `const` contexts to allow for more fields in `Resolver` to have a default value. `FxIndexSet`/`FxIndexMap` are still outstanding and not const-buildable.
r? @petrochenkov
simplify words initialization using Rc::new_zeroed
Now that Rc::new_zeroed is stable, remove the cfg(feature = "nightly") branch and the temporary zeroed array on stable. This avoids copying a potentially large [Word; CHUNK_WORDS] into the Rc.
Support primitives in type info reflection
Tracking issue: rust-lang/rust#146922 `#![feature(type_info)]`
This PR supports {`bool`,`char`,`int`,`uint`,`float`,`str`} primitive types for feature `type_info` reflection.
r? @oli-obk
Cache derive proc macro expansion with incremental query
This is a revival of https://github.com/rust-lang/rust/pull/129102, originally implemented by @futile. Since it looks like they are not active currently, I'd like to push this work forward.
The first commit is squashed and rebased work from the original PR, with author attribution to futile. The rest of the commits are some additional comments that I created mostly for myself to understand what happens here. I also did some cleanups based on Vadim's review comments on the original PR, plus I refactored the TLS access a bit using `scoped_tls`.
The biggest issue, as usually, are tests... I tried using `#[rustc_clean(..., loaded_from_disk = "derive_macro_expansion")]`, but the problem is that since this query cannot recover the original key from its hash, and thus its fingerprintstyle is `FingerprintStyle::Opaque`, [this](2fef0a30ae/compiler/rustc_incremental/src/persist/dirty_clean.rs (L388)) crashes when I try to use `loaded_from_disk`. Any suggestions from someone who actually understands the query system would be welcome 😅
TODO: document the new unstable flag
On a no-op change re-check of `octocrab 0.49` (which has a ton of `serde` derive proc macro invocations), this saves ~0.6s out of ~6s (so a ~10% win) on my PC.
r? @petrochenkov
This PR adds an additional help note to the ambiguity lint error output
to ask users updating their dependencies. This hopefully helps with
cases like https://github.com/rust-lang/rust/issues/149845 where newer crate versions are fixed.
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
PR #138672 introduced a complex and invasive split of `QueryStackFrame`
to avoid a query cycle. This commit reverts that change because there is
a much simpler change that fixes the problem, which will be in the next
commit.
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.
Issue #124901 was an OOM caused by a query cycle. It was fixed by
a complex change in PR #138672, but that PR did not add the test case.
Let's add it now, because it's the only known reproducer of the OOM.
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.
