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
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
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.
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.
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.
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
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
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.
Improve span for "unresolved intra doc link" on `deprecated` attribute
Follow-up of rust-lang/rust#150721.
To make this work, I replaced the `Symbol` by an `Ident` to keep the `Span` information.
cc @folkertdev
r? @camelid
Use a hook to decouple `rustc_mir_transform` from `rustc_mir_build`
I noticed that the only point of direct contact between the `rustc_mir_transform` and `rustc_mir_build` crates is a single `build_mir` function, which could easily be changed to a hook function instead.
By making that function a hook, we can make `rustc_mir_transform` no longer have a dependency on `rustc_mir_build`, allowing them to be built/rebuilt independently. That should hopefully allow slightly more parallelism in clean builds and incremental rebuilds of the compiler.
Port `#[rustc_has_incoherent_inherent_impls]` to attribute parser
Tracking issue: rust-lang/rust#131229
no tests changed here at all, so maybe we should add some but would like to know what kind of tests would be good to add
r? @JonathanBrouwer
Also hash spans inside the same file as relative (V2)
Hashes spans relatively to their parent, even if they are not contained inside their parent.
Fixes https://github.com/rust-lang/rust/issues/150400
Closes https://github.com/rust-lang/rust/pull/143882, as this is a successor PR
This PR is very closely based on that PR with a few minor changes, so to give proper credit I made @cjgillot coauthor of the commit.
Fix ICE: can't type-check body of DefId for issue #148729
This commit fixes https://github.com/rust-lang/rust/issues/148729 for min_const_generic_args https://github.com/rust-lang/rust/issues/132980.
It's pretty small PR. The first commit makes sure that the `type_const`s are made into normal consts in const expressions.
The next one just handles the case https://github.com/rust-lang/rust/issues/148729 of where the type of the const was omitted at which point it was trying to treat a `type_const` again as a regular const. That obviously will fail since a type_const does not have a body.
@rustbot label +F-associated_const_equality +F-min_generic_const_args +I-ICE
THIR patterns: Replace `AscribeUserType` and `ExpandedConstant` wrappers with per-node data
This PR removes the `AscribeUserType` and `ExpandedConstant` variants from `thir::PatKind`, and replaces them with an `Option<Box<PatExtra>>` field attached to every `thir::Pat`.
### Why remove these variants?
Unlike other THIR pattern kinds, these variants are mere “wrappers” that exist to attach some additional information to an underlying pattern node.
There are several places where code that consumes THIR patterns needs to carefully “unpeel” any wrapper nodes, in order to match on the underlying pattern. This is clunky, and easy to forget to do, especially since it's not always obvious where the wrapper nodes can and can't appear.
Attaching the data to an optional per-node field makes it easier for consuming code to simply ignore the extra data when it is not relevant.
(One downside is that it is now easier to accidentally ignore the extra data when it *is* relevant, but I think that's generally a favourable tradeoff.)
### Impact
After this change, THIR pattern trees should be “logically identical” to the previous THIR pattern trees, in the sense that information that was carried by wrapper nodes should now be directly attached to the non-wrapper nodes that were being wrapped. Types and spans associated with THIR pattern nodes should (hopefully!) still be accurate.
There should be no change to the output of THIR-based checks or MIR building.
Handling for inherent associated consts is missing elsewhere, remove so it can be handled later in that handling.
Diagnostic not always be emitted on associated constant
Add a test case and Fix for a different ICE I encountered.
I noticed when trying various permuations of the test case code to see if I could find anymore ICEs. I did, but not one that I expected. So in the instances of the a named const not having any args, insantiate it directly. Since it is likely an inherent assocaiated const.
Added tests.
Centralize the is_type_const() logic.
I also noticed basically the exact same check in other part the code.
Const blocks can't be a type_const, therefore this check is uneeded.
Fix comment spelling error.
get_all_attrs is not valid to call for all DefIds it seems.
Make sure that if the type is omitted for a type_const that we don't ICE.
Co-Authored-By: Boxy <rust@boxyuwu.dev>
Store defids instead of symbol names in the aliases list
I was honestly surprised this worked in the past. This causes a cycle error since we now compute a symbol name in codegen_attrs, and then compute codegen attrs when we try to get the symbol name.
It only worked when there weren't any codegen attributes to begin with, causing symbol name computation to skip the call to codegen_attrs.
Like this we won't have the same problem.
r? @bjorn3
Variables that are collections of `CanonicalVarKind` are sometimes
called `var_kinds` and sometimes called `variables`. The former is much
better, because `variables` is (a) non-descript, and (b) often used
nearby for collections of `I::GenericArg`. I found the inconsistency
made the canonicalization code harder to understand.
This commit renames various `variables` things as `var_kinds`.
This removes `associated_const_equality` as a separate feature gate and makes it part of `min_generic_const_args` (mgca).
Key changes:
- Remove `associated_const_equality` from unstable features, add to removed
- Update all test files to use `min_generic_const_args` instead
- Preserve the original "associated const equality is incomplete" error message by specially handling `sym::associated_const_equality` spans in `feature_gate.rs`
- Rename FIXME(associated_const_equality) to FIXME(mgca)
Detect cases where `?` is applied on a type that could be coming from a different crate version than expected
```
error[E0277]: `?` couldn't convert the error to `dependency::Error`
--> replaced
|
LL | fn main() -> Result<(), Error> {
| ----------------- expected `dependency::Error` because of this
...
LL | Err(Error2)?;
| -----------^ the trait `From<Error2>` is not implemented for `dependency::Error`
| |
| this can't be annotated with `?` because it has type `Result<_, Error2>`
|
= note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
help: the trait `From<Error2>` is not implemented for `dependency::Error`
but trait `From<()>` is implemented for it
--> replaced
|
LL | impl From<()> for Error {
| ^^^^^^^^^^^^^^^^^^^^^^^
= help: for that trait implementation, expected `()`, found `Error2`
= note: there are multiple different versions of crate `dependency` in the dependency graph
= help: you can use `cargo tree` to explore your dependency tree
```
The existing checks rely on having access to the actual types/traits that diverged to detect they are called the same, come from different crates with the same name. The new check is less specific, merely looking to see if the crate name the involved type belongs has multiple crates.
CC rust-lang/rust#78552.
mir_build: Separate match lowering for string-equality and scalar-equality
- Follow-up to https://github.com/rust-lang/rust/pull/150238
---
This PR takes some match-lowering code that is responsible for equality tests, and splits it into distinct code paths for string-equality and scalar-equality.
The split results in more lines of code overall, but makes the separated code paths easier to understand individually.
r? Nadrieril
Use more principled check for generics in const ops
Fixesrust-lang/rust#144547.
Fixesrust-lang/rust#140891.
In the future, we likely want to make the check less likely to be missed by reducing the number of external entry points to HIR type lowering.
Note: If this causes pass->error regressions (not truly regressions because those cases were mistakenly accepted), they can easily be avoided for the time being by only running the check if `is_self_alias` is true or mgca is enabled.
- **Fix parsing of mgca const blocks in array repeat exprs**
- **Use more principled check for generics in const ops**
Instead of using a visitor in typeck, we just check, whenever lowering a
use of a param, whether the parent item is an MCG anon const during hir
ty lowering (and instantiate_value_path). If so, we report an error
since MCG anon consts should never be able to use generics. All other
kinds of anon consts are at least syntactically allowed to use generic
params.
We use a `TypeFolder` to accomplish this; this way, we look at the
fully explicit semantic representation of the type/const/whatever and
don't miss subtle cases like `Self` type aliases.
