According to its comment, this query was only using `anon` to save a little bit
of work for a dep graph node that is expected to have no dependencies.
Benchmarks indicate that the perf loss, if any, is small enough to be justified
by the fact that we can now remove support for `anon` queries.
Adding `no_hash` appears to give marginally better perf results.
These queries appear to have been using `anon` for its side-effect of making
them ineligible for forcing.
According to their comments and also `tests/incremental/issue-61323.rs`, these
queries want to avoid forcing so that if a cycle does occur, the whole cycle
will be on the query stack for the cycle handler to find.
Guard patterns: lowering to THIR
This pr implements lowering of guard patterns to THIR
r? @Nadrieril
cc @max-niederman
Tracking issue: rust-lang/rust#129967
ty-aware delayed AST -> HIR lowering
This PR implements a prototype of ty-aware delayed AST -> HIR lowering. Part of rust-lang/rust#118212.
r? @petrochenkov
# Motivation
When lowering delegation in perfect scenario we would like to access the ty-level information, in particular, queries like `generics_of`, `type_of`, `fn_sig` for proper HIR generation with less hacks. For example, we do not want to generate more lifetimes than needed, because without ty-level queries we do not know which delegee's lifetimes are late-bound. Next, consider recursive delegations, for their proper support without ty we would have to either duplicate generics inheritance code in AST -> HIR lowering or create stubs for parts of the HIR and materialize them later. We already use those queries when interacting with external crates, however when dealing with compilation of a local crate we should use resolver for similar purposes. Finally, access to ty-level queries is expected to help supporting delegation to inherent impls, as we can not resolve such calls during AST -> HIR stage.
# Benefits
We eliminate almost all code that uses resolver in delegation lowering:
- Attributes inheritance is done without copying attributes from AST at resolve stage
- Fn signatures are obtained from `tcx.fn_sig`
- Param counts are also obtained from `tcx.fn_sig`
- `is_method` function now uses `tcx.associated_item` instead of resolver
- Generics are now inherited through `get_external_generics` that uses `tcx.generics_of`. Generics for recursive delegations should also work
- `DelegationIds` that stored paths for recursive delegations is removed, we now use only `delegee_id`
- Structs that were used for storing delegation-related information in resolver are almost fully removed
- `ast_index` is no more used
# Next steps
- Remove creating generic params through AST cloning, proper const types propagation
- Inherent impls
# High level design overview
## Queries
We store ids of delayed items to lower in `Crate` struct. During first stage of lowering, owners that correspond to delayed items are filled with `MaybeOwner::Phantom`.
Next, we define two new queries: `lower_delayed_owner`, `delayed_owner` and a function `force_delayed_owners_lowering`.
The first query is used when lowering known (which is in `delayed_ids`) delayed owner.
The second is fed with children that were obtained during lowering of a delayed owner (note that the result of lowering of a single `LocalDefId` is not a single `MaybeOwner`, its a list of `(LocalDefId, MaybeOwner)` where the first `MaybeOwner` corresponds to delayed `LocalDefId` and others to children that were obtained during lowering (i.e. generic params)). By default `delayed_owner` returns `MaybeOwner::Phantom`. As we do not want to predict the whole list of children which will be obtained after lowering of a single delayed item, we need to store those children somewhere. There are several options:
- Make the return type of `lower_delayed_owner` to be `FxIndexMap<LocalDefId, MaybeOwner>` and search children here. Search will be either linear or we can introduce a map somewhere which will track parent-child relations between a single delayed `LocalDefId` and its children.
- Try to make query that will lower all delayed items in a loop and return a complete map of all delayed `LocalDefIds` and their children. In this case there will be problems with delayed items that require information about other delayed items.
By using proposed queries we handle the second concern, and in case of acyclic dependencies between delayed ids it automatically works, moreover we use queries as cache for delayed `MaybeOwners`. The only invariant here is that queries which are invoked during delayed AST -> HIR lowering of some `LocalDefId` should not in any way access children of other, yet unlowered, delayed `LocalDefId`, they should firstly materialize it.
The `force_delayed_owners_lowering` forces lowering of all delayed items and now integrated in `hir_crate_items` query.
## Resolver for lowering
> ~Currently the `resolver_for_lowering` is stolen in `lower_to_hir` function, however we want to prolong its life until all delayed `LocalDefIds` are materialized. For this purpose we borrow `resolver_for_lowering` in `lower_to_hir` and drop it after forcing materialization of all delayed `LocalDefId` in `rustc_interface::run_required_analyses`.~
We split resolver for lowering into two parts: the first part is a readonly part that came to us from resolve, the second part is a mutable part that can be used to add or overwrite values in the readonly part. Such splitted resolver is used during delayed lowering, as we can't steal it.
## AST index
Lowering uses an AST index. It is created in `lower_to_hir` function and it references parts of AST. We want to avoid reindexing AST on every delayed `LocalDefId` lowering, however now it is not clear how to properly do it. As delayed HIR lowering is used only for delegation unstable feature it should not affect other use-cases of the compiler. But it will be reworked sooner or later.
Rewrite `query_ensure_result`.
It currently uses chaining which is concise but hard to read. There are up to four implicit matches occurring after the call to `execute_query_fn`.
- The first `map` on `Option<Erased<Result<T, ErrorGuaranteed>>>`.
- The second `map` on `Option<Result<T, ErrorGuaranteed>>`.
- The third `map` on `Result<T, ErrorGuaranteed>`.
- The `unwrap_or` on `Option<Result<(), ErrorGuaranteed>>`.
This commit rewrites it to use at most two matches.
- An explicit match on `Option<Erased<Result<T, ErrorGuaranteed>>>`.
- An explicit match on `Result<T, ErrorGuaranteed>`.
This is easier to read. It's also more efficient, though the code isn't hot enough for that to matter.
r? @Zalathar
fix inference variables leaking into HIR const literal lowering logic
Inference variables could leak into further const lowering logic
It ICEs when query system tries to cache `lit_to_const()` after its execution and panics, because inference variables are not hashable for some reason
Fixesrust-lang/rust#153524Fixesrust-lang/rust#153525
It currently uses chaining which is concise but hard to read. There are
up to four implicit matches occurring after the call to
`execute_query_fn`.
- The first `map` on `Option<Erased<Result<T, ErrorGuaranteed>>>`.
- The second `map` on `Option<Result<T, ErrorGuaranteed>>`.
- The third `map` on `Result<T, ErrorGuaranteed>`.
- The `unwrap_or` on `Option<Result<(), ErrorGuaranteed>>`.
This commit rewrites it to use at most two matches.
- An explicit match on `Option<Erased<Result<T, ErrorGuaranteed>>>`.
- An explicit match on `Result<T, ErrorGuaranteed>`.
This is easier to read. It's also more efficient, though the code isn't
hot enough for that to matter.
This is nitpicky, but the lack of a sensible order has been bugging me.
- Within `mod $name`, put all the typedefs together.
- After that:
- First, types definitions and their impls.
- Then the `TyCtxt*` impls, in a sensible order.
- Likewise, put `TyCtxt::at` before the similar methods.
- Also reflow some overly long lines.
All methods that accept `impl IntoQueryKey<_>` have been adjusted to
consistently call `into_query_key` before doing anything else.
When a function with a conversion trait calls another function with the same
conversion trait, doing the conversion eagerly can reduce the overall number of
instantiations.
Removing coherent and self-contained chunks of code from a catch-all "plumbing"
module is typically an improvement.
Giving the trait its own file also gets rid of the unhelpful `sealed` module
that it was previously in.
Code that previously used `QueryStackFrame` now uses `TaggedQueryKey` directly.
Code that previously used `Spanned<QueryStackFrame>` now uses
`QueryStackFrame`, which includes a span.
Remove redundant fields from `QueryStackFrame`
- Follow-up to https://github.com/rust-lang/rust/pull/153867#discussion_r2935993621
---
Now that QueryStackFrame holds a TaggedQueryKey, it turns out that all of its other fields are redundant and can be removed:
- An explicit dep-kind is redundant here. If we want to find the query name, or check for specific queries, we can inspect the `TaggedQueryKey` instead.
- Similarly, in cases where the key is some kind of `DepId`, we can extract it directly from the `TaggedQueryKey`.
r? nnethercote
Don't look for non-type-level assoc consts when checking trait object types
On main, when looking for assoc items that weren't specified in a given trait object type (via binding), we comb through all (eligible) assoc consts whether type-level or not even though you're not allowed to bind non-type-level assoc consts.
That's usually fine because traits containing (eligible) non-type-level assoc consts are dyn incompatible, so the trait object type is ~already considered ill-formed. Therefore, in PR rust-lang/rust#150843, I saved myself the extra effort, esp. since back then it was more annoying to check if the const item was declared type-level.
<sub>(More concretely: In bodies, we check for all dyn compatibility violations when lowering the trait object type, so we will bail out early with an error; in contrast, item signatures / non-bodies get wfchecked (`WellFormed` obligation) after lowering which includes dyn compatiblity checking (`DynCompatible` obligation); however to reduce the amount of diags, during lowering if there are any unspecified assoc items, we'll check them for dyn compatibility and bail out early if any of them tests negative.)</sub>
Now, we obviously don't wfcheck the defsite of (eager) type aliases which breaks the assumption that such trait object types get rejected. This led to the regression found in rust-lang/rust#153731: The ill-formed trait object type doesn't get rejected (as is expected) but we now require the single (non-type-level) assoc const to be bound in the dyn-Trait which we didn't do before. The actual error talks about dyn incompatibility due to the aforementioned extra check that's usually there to contain the number of diags.
Fixes [after beta backport] rust-lang/rust#153731.
An explicit dep-kind is redundant here. If we want to find the query name, or
check for specific queries, we can inspect the `TaggedQueryKey` instead.
Similarly, in cases where the key is some kind of `DefId`, we can extract it
directly from the `TaggedQueryKey`.
Re-export `rustc_middle::query::{QuerySystem, QueryVTable}`
- Follow-up to https://github.com/rust-lang/rust/pull/153760#discussion_r2928848418.
---
All of the other public items in `rustc_middle::query::plumbing` are re-exported from `query`, except for these two, for no particular reason that I can see.
Re-exporting them allows `rustc_middle::query::plumbing` to have its visibility reduced to pub(crate).
Imports within `rustc_middle` have also been updated to consistently use the re-exports in `crate::query`.
r? nnethercote
Rename all-query functions.
There are four functions that use `for_each_query_vtable!` to call an "inner" function. They are:
- `collect_active_jobs_from_all_queries` -> `gather_active_jobs`
- `alloc_self_profile_query_strings` -> `alloc_self_profile_query_strings_for_query_cache`
- `encode_all_query_results` -> `encode_query_results`
- `query_key_hash_verify_all` -> `query_key_hash_verify`
These names are all over the place. This commit renames them as follows:
- `collect_active_query_jobs{,_inner}`
- `alloc_self_profile_query_strings{,_inner}`
- `encode_query_values{,_inner}`
- `verify_query_key_hashes{,_inner}`
This:
- puts the verb at the start
- uses `_inner` for all the inners (which makes sense now that the inners are all next to their callers)
- uses `_query_` consistently
- avoids `all`, because the plurals are enough
- uses `values` instead of `results`
- removes the `collect`/`gather` distinction, which is no longer important
r? @Zalathar
All of the other public items in `rustc_middle::query::plumbing` are
re-exported from `query`, except for these two, for no particular reason that I
can see.
Re-exporting them allows `rustc_middle::query::plumbing` to have its visibility
reduced to pub(crate).
Imports within `rustc_middle` have also been updated to consistently use the
re-exports in `crate::query`.
There are four functions that use `for_each_query_vtable!` to call an "inner"
function. They are:
- collect_active_jobs_from_all_queries -> gather_active_jobs
- alloc_self_profile_query_strings -> alloc_self_profile_query_strings_for_query_cache
- encode_all_query_results -> encode_query_results
- query_key_hash_verify_all -> query_key_hash_verify
These names are all over the place. This commit renames them as follows:
- collect_active_query_jobs{,_inner}
- alloc_self_profile_query_strings{,_inner}
- encode_query_values{,_inner}
- verify_query_key_hashes{,_inner}
This:
- puts the verb at the start
- uses "inner" for all the inners (which makes sense now that the inners are
all next to their callers)
- uses `_query_` consistently
- avoids `all`, because the plurals are enough
- uses `values` instead of `results`
- removes the `collect`/`gather` distinction, which is no longer
important
`CycleError` has one field containing a `(Span, QueryStackFrame<I>)` and
another field containing a `QueryInfo`, which is a struct containing
just a `Span` and a `QueryStackFrame<I>`.
We already have the `Spanned` type for adding a span to something. This
commit uses it for both fields in `CycleError`, removing the need for
`QueryInfo`. Which is good for the following reasons.
- Any type with `Info` in the name is suspect, IMO.
- `QueryInfo` can no longer be confused with the similar `QueryJobInfo`.
- The doc comment on `QueryInfo` was wrong; it didn't contain a query
key.
Use less `#[macro_use]` in the query system
Macro-rules namespacing and import/export is a bit of a nightmare in general. We can tame it a bit by avoiding `#[macro_use]` as much as possible, and instead putting a `pub(crate) use` after the macro-rules declaration to make the macro importable as a normal item.
I've split this PR into two commits. The first one should hopefully be uncontroversial, while the second commit takes the extra step of declaring `rustc_with_all_queries!` as a macros-2.0 macro, which gives much nicer import/export behaviour, at the expense of having to specify `#[rustc_macro_transparency = "semiopaque"]` to still have access to macro-rules hygiene, because the default macros-2.0 hygiene is too strict here.
There should be no change to compiler behaviour.
---
I stumbled into this while investigating some other changes, such as re-exporting `rustc_middle::query::QueryVTable` or moving the big callback macro out of `rustc_middle::query::plumbing`. I think it makes sense to make this change first, to make other module-juggling tasks easier.
r? nnethercote (or compiler)
Remove `def_id_for_ty_in_cycle`
This removes `QueryKey::def_id_for_ty_in_cycle` and `QueryStackFrame.def_id_for_ty_in_cycle` by computing it instead from `TaggedQueryKey`.
Don't pass a separate `DepKind` to `query_feed`
This PR makes two small tweaks to the `query_feed` function, which is called by macro-generated methods on TyCtxtFeed:
- Don't pass `DepKind` as a separate argument, because it's already in the QueryVTable
- Rename `query_vtable` to `query`, to match other functions that take QueryVTable
r? nnethercote (or compiler)
Reimplement const closures
Tracking issue: rust-lang/rust#106003
Best reviewed commit-by-commit
The old solver can't handle `for<'a> |x: &'a()| ()` closures in const contexts, but that feature is unstable itself, so we can just leave it to the next solver to handle.
We need a lot more tests, we're testing the bare minimum of success and failure paths right now.
r? @fee1-dead
Replace `visit_waiters` with `abstracted_waiters_of`
This replaces `visit_waiters` which uses closures to visit waiters with `abstracted_waiters_of` which returns a list of waiters. This makes the control flow of their users a bit clearer.
Additionally `abstracted_waiters_of` includes non-query waiters unlike `visit_waiters`. This means that `connected_to_root` now considers resumable waiters from the compiler root as being connected to root, while previously only non-resumable waiters counted. This can result in some additional entry points being found. Similarly in the loop detecting entry points we now consider queries in the cycle with direct resumable waiters from the compiler root as being entry points.
When looking for entry points we now look at waiters until we found a query to populate the `EntryPoint.waiter` field instead of stopping when we determined it to be an entry point.
cc @petrochenkov @nnethercote
LinkedGraph: support adding nodes and edges in arbitrary order
If an edge uses some not-yet-known node, we just leave the node's data empty, that data can be added later.
Use this support to avoid skipping edges in RetainedDepGraph.
This is continuation of https://github.com/rust-lang/rust/pull/152590, that PR just fixes the ICE, this PR also preserves all the edges in debug dumps.
This is also a minimized version of https://github.com/rust-lang/rust/pull/151821 with a smaller amount of data structure hacks.
The query's dep kind can be obtained from its vtable instead.
This commit also renames the `query_vtable` parameter to `query`, to be more
consistent with other functions that take a QueryVTable.
Currently if a cycle error occurs the error is created, then handled
according to `CycleErrorHandling` (which comes from the
`cycle_delay_bug` query modifer, or lack thereof), and then
`value_from_cycle_error` is called.
This commit changes things so the error is created and then just passed
to `value_from_cycle_error`. This gives `value_from_cycle_error` full
control over how it's handled, eliminating the need for
`CycleErrorHandling`. This makes things simpler overall.
Add a `TaggedQueryKey` to identify a query instance
This adds back a `TaggedQueryKey` enum which represents a query kind and the associated key. This is used to replace `QueryStackDeferred` and `QueryStackFrameExtra` and the associated lifting operation for cycle errors
This approach has a couple of benefits:
- We only run description queries when printing the query stack trace in the panic handler
- The unsafe code for `QueryStackDeferred` is removed
- Cycle handles have access to query keys, which may be handy
Some further work could be replacing `QueryStackFrame` with `TaggedQueryKey` as the extra information can be derived from it.
Zalathar