From `plumbing.rs` to `execution.rs`, which is where most of the other
query profiling occurs. It also avoids eliminates some fn parameters.
This means the `provided_to_erased` call in `try_from_load_disk_fn` is
now included in the profiling when previously it wasn't. This is
good because `provided_to_erased` is included in other profiling calls
(e.g. calls to `invoke_provider_fn`).
It doesn't need to be in there, it can instead be at the single call
site. Removing it eliminates one parameter, makes `define_queries!`
smaller (which is always good), and also enables the next commit which
tidies up profiling.
This commit also changes how `value` and `verify` are initialized,
because I don't like the current way of doing it after the declaration.
This modifier indicates that a query has a custom handler for cycles.
That custom handler must be found at
`rustc_query_impl::handle_cycle_error::$name`.
This eliminates the need for `specialize_query_vtables`, which is the
current hack to install custom handlers. It's more lines of code in
total, but indicating special treatment of a query via a modifier in
`queries.rs` is more consistent with how other aspects of queries are
handled.
`rustc_queries` generates a macro and two modules. One of the modules
looks like this:
```
mod _description_fns {
...
#[allow(unused_variables)]
pub fn hir_module_items<'tcx>(tcx: TyCtxt<'tcx>, key: LocalModDefId) -> String {
format!("getting HIR module items in `{}`", tcx.def_path_str(key))
}
...
}
```
Members of this module are then used in `TaggedQueryKey::description`.
This commit removes the `_description_fns` module entirely. For each
query we now instead generate a description closure that is used
instead. This closure is passed in the modifiers list.
This change simplifies `rustc_queries` quite a bit. It requires adding
another query modifier, but query modifiers are how other query-specific
details are already passed to the declarative macros, so it's more
consistent.
Queries with both `cache_on_disk` and `separate_provide_extern` will only
disk-cache values for local keys.
Other queries with `cache_on_disk` will disk-cache all values unconditionally.
The existing names have bugged me for a while. Changes:
- `CycleError` -> `Cycle`. Because we normally use "error" for a `Diag`
with `Level::Error`, and this type is just a precursor to that. Also,
many existing locals of this type are already named `cycle`.
- `CycleError::cycle` -> `Cycle::frames`. Because it is a sequence of
frames, and we want to avoid `Cycle::cycle` (and `cycle.cycle`).
- `cycle_error` -> `find_and_handle_cycle`. Because that's what it does.
The existing name is just a non-descript noun phrase.
- `mk_cycle` -> `handle_cycle`. Because it doesn't make the cycle; the
cycle is already made. It handles the cycle, which involves (a)
creating the error, and (b) handling the error.
- `report_cycle` -> `create_cycle_error`. Because that's what it does:
creates the cycle error (i.e. the `Diag`).
- `value_from_cycle_error` -> `handle_cycle_error_fn`. Because most
cases don't produce a value, they just emit an error and quit.
And the `_fn` suffix is for consistency with other vtable fns.
- `from_cycle_error` -> `handle_cycle_error`. A similar story for this
module.
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.
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`.
Unlike `macro_rules!`, macros-2.0 macros have sensible item-like namespacing
and visibility by default, which avoids the need for `#[macro_export]` and
makes it easier to import the macro.
The tradeoff is having to use `#[rustc_macro_transparency = "semiopaque"]` to
still get macro-rules hygiene, because macros-2.0 hygiene is too strict here.
Moving the macro and its expansion into the same physical file resolves a lot
of tension in the current module arrangement.
Code in the macro is now free to use plain imports in the same file, and there
is no longer any question of whether `mod query_impl` should be declared inside
the macro, or surrounding a separate expansion site.
Nicholas Nethercote