If we make sure that `compute_fn` in the query's vtable is actually named
`__rust_begin_short_backtrace`, we can avoid the need for some additional
intermediate functions and stack frames.
This is similar to how the `get_query_incr` and `get_query_non_incr` functions
are actually named `__rust_end_short_backtrace`.
Use the query vtable in `query_feed` plumbing
The `query_feed` function needs to be able to do two important things with (erased) query values: hash them, and debug-print them.
Both of those are things that the query's vtable already knows how to do. So by passing in a vtable to `query_feed`, we can give it a nicer signature, avoid having to unerase values in the function itself, and clean up some caller-side code as well.
Various `QueryStackFrame` variables are called `query`; `frame` is a
better name. And various `QueryInfo` variables are called `frame`;
`info` is a better name.
This eliminates some confusing `query.query()` occurrences, which is a
good sign, and some `frame.query` occurrences become `info.frame`.
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
error[E0277]: can't compare `SomeNode` with `SomeNode`
--> f29.rs:24:15
|
24 | accept_eq(&node);
| --------- ^^^^^ no implementation for `SomeNode == SomeNode`
| |
| required by a bound introduced by this call
|
= note: -Ztrack-diagnostics: created at compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs:279:39
= help: the trait `PartialEq` is not implemented for `SomeNode`
note: required for `Id<SomeNode>` to implement `PartialEq`
--> f29.rs:3:10
|
3 | #[derive(PartialEq, Eq)]
| ^^^^^^^^^ unsatisfied trait bound introduced in this `derive` macro
4 | pub struct Id<T>(PhantomData<T>);
| -
= help: consider manually implementing `PartialEq` to avoid undesired bounds
note: required by a bound in `accept_eq`
--> f29.rs:15:23
|
15 | fn accept_eq(_: &impl PartialEq) { }
| ^^^^^^^^^ required by this bound in `accept_eq`
help: consider annotating `SomeNode` with `#[derive(PartialEq)]`
|
13 + #[derive(PartialEq)]
14 | struct SomeNode();
|
```
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`
Also returns the `Region` of the reference type in `Ty::maybe_pinned_Ref`.
Part of rust-lang/rust#149130.
r? jackh726
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think seeing the type would be better.
constify `Iterator`, take IV
Like its predecessors (rust-lang/rust#92433, rust-lang/rust#102225, rust-lang/rust#106541), this PR allows one to make `Iterator` implementations `const`, and thus enables the ability to have `for` loops in `const` contexts. I've also included constifying `Option as IntoIterator`, `option::IntoIter as Iterator` as a minimal dogfooding example.
But unlike its predecessors, it uses a new attribute (not unsound anymore!) that prevents any `Iterator` extension methods from being called. This is intentionally made minimal for an initial approval, the fun stuff like `.fold`, `Range as Iterator` could be done later.
cc @rust-lang/wg-const-eval, cc @oli-obk to review the compiler parts
cc rust-lang/rust#92476
Remove redundant `IntoQueryParam` calls from query plumbing
In each of these contexts, the key must have already been converted by the caller, since otherwise it wouldn't have type `Cache::Key`.
There should be no change to compiler behaviour.
`QueryStackFrame<I>` is a generic type, and the `I` parameter leaks out
to many other related types. However, it only has two instantiations in
practice:
- `QueryStackFrame<QueryStackFrameExtra>`
- `QueryStackFrame<QueryStackDeferred<'tcx>>`
And most of the places that currently use `QueryStackFrame<I>` are
actually specific to one of the instantiations. This commit removes the
unneeded genericity.
The following types are only ever used with `QueryStackDeferred<'tcx>`:
- QueryMap
- QueryJobInfo
- QueryJob
- QueryWaiter
- QueryLatchInfo
- QueryLatch
- QueryState
- QueryResult
and their `<I>` parameter is changed to `<'tcx>`.
Also, the `QueryContext::QueryInfo` associated type is removed.
`CycleError<I>` and `QueryInfo<I>` are still generic over type, because
they are used with both instantiations.
This required also adding a `<'tcx>` parameter to the traits
`QueryDispatcher` and `QueryContext`, which is annoying but I can't see
how to avoid it.
Rename, clarify, and document code for "erasing" query values
In order to reduce compile times and code size for the compiler itself, the query system has a mechanism for “erasing” and ”restoring” query values in certain contexts. See https://github.com/rust-lang/rust/pull/109333 for the original implementation.
Unfortunately, the erasure system has very little documentation, and involves a dizzying assortment of similarly-named types, traits, and functions.
This PR therefore renames several parts of the erasure API and implementation to hopefully be clearer, and adds comments to better explain the purpose and mechanism behind value erasure.
Summary of renames:
- fn `erase` → `erase_val` (avoiding ambiguity with module `erase`)
- fn `restore` → `restore_val`
- type `Erase<T>` → `Erased<T>` (for actual erased values of `T`)
- trait `EraseType` → `Erasable` (for types that can be erased and restored)
- associated type `EraseType::Result` → `Erasable::Storage`
- implementation-detail struct `Erased<T>` → `ErasedData<Storage>`
There should be no change to compiler behaviour.
Use an associated type default for `Key::Cache`.
They currently aren't used because r-a didn't support them, but r-a support was recently merged in
https://github.com/rust-lang/rust-analyzer/pull/21243.
r? @Noratrieb
Reintroduce `QueryStackFrame` split.
I tried removing it in rust-lang/rust#151203, to replace it with something simpler. But a couple of fuzzing failures have come up and I don't have a clear picture on how to fix them. So I'm reverting the main part of rust-lang/rust#151203.
This commit also adds the two fuzzing tests.
Fixesrust-lang/rust#151226, rust-lang/rust#151358.
r? @oli-obk
I tried removing it in #151203, to replace it with something simpler.
But a couple of fuzzing failures have come up and I don't have a clear
picture on how to fix them. So I'm reverting the main part of #151203.
This commit also adds the two fuzzing tests.
Fixes#151226, #151358.
