In #101230, the internal diagnostic migration lints -
`diagnostic_outside_of_impl` and `untranslatable_diagnostic` - were
modified so that they wouldn't trigger on functions annotated with
`#[rustc_lint_diagnostics]`. However, this change has to make it into
the bootstrap compiler before the `#[allow]` annotations that it aims to
remove can be removed, which is possible now that #102051 has landed.
Signed-off-by: David Wood <david.wood@huawei.com>
macros: diagnostic derive on enums
Part of #100717.
Extends `#[derive(Diagnostic)]` to work on enums too where each variant acts like a distinct diagnostic - being able to represent diagnostics this way can be quite a bit simpler for some parts of the compiler.
r? `@compiler-errors`
cc `@Xiretza`
LLVM 15 added `Optional::has_value`, and LLVM `main` (16) has deprecated
`hasValue`. However, its `explicit operator bool` does the same thing,
and was added long ago, so we can use that across our full LLVM range of
compatibility.
Rollup of 5 pull requests
Successful merges:
- #101875 (Allow more `!Copy` impls)
- #101996 (Don't duplicate region names for late-bound regions in print of Binder)
- #102181 (Add regression test)
- #102273 (Allow `~const` bounds on non-const functions)
- #102286 (Recover some items that expect braces and don't take semicolons)
Failed merges:
- #102314 (Add a label to struct/enum/union ident name)
r? `@ghost`
`@rustbot` modify labels: rollup
Allow more `!Copy` impls
You can already implement `!Copy` for a lot of types (with `#![feature(negative_impls)]`). However, before this PR you could not implement `!Copy` for ADTs whose fields don't implement `Copy` which didn't make any sense. Further, you couldn't implement `!Copy` for types impl'ing `Drop` (equally nonsensical).
``@rustbot`` label T-types F-negative_impls
Fixes#101836.
r? types
Fix lint scoping for let-else.
The scoping for let-else is inconsistent with HIR nesting. This creates cases, in `ui/let-else/let-else-allow-unused.rs` for instance, where an `allow` lint attribute does not apply to the bindings created by `let-else`.
This PR is an attempt to correct this.
As there is no lint that currently relies on this, the test for this behaviour is https://github.com/rust-lang/rust/pull/101500.
cc `@dingxiangfei2009` as you filed https://github.com/rust-lang/rust/pull/101894
Update bootstrap compiler to 1.65.0
This PR updates the bootstrap compiler to Rust 1.65.0, removing the various `cfg(bootstrap)`s.
r? `@Mark-Simulacrum`
Rollup of 5 pull requests
Successful merges:
- #102143 (Recover from struct nested in struct)
- #102178 (bootstrap: the backtrace feature is stable, no need to allow it any more)
- #102197 (Stabilize const `BTree{Map,Set}::new`)
- #102267 (Don't set RUSTC in the bootstrap build script)
- #102270 (Remove benches from `rustc_middle`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove benches from `rustc_middle`
These benches benchmark rust langauge features and not the compiler, so they seem to be in the wrong place here. They also all take <1ns, making them pretty useless. Looking at their git history, they just seem to have been carried around for many, many years. This commit ends their journey.
Stabilize const `BTree{Map,Set}::new`
The FCP was completed in #71835.
Since `len` and `is_empty` are not const stable yet, this also creates a new feature for them since they previously used the same `const_btree_new` feature.
`Cursor` keeps track of the position within the current token. But it
uses confusing names that don't make it clear that the "length consumed"
is just within the current token.
This commit renames things to make this clearer.
`Cursor` is currently hidden, and the main tokenization path uses
`rustc_lexer::first_token` which involves constructing a new `Cursor`
for every single token, which is weird. Also, `first_token` also can't
handle empty input, so callers have to check for that first.
This commit makes `Cursor` public, so `StringReader` can contain a
`Cursor`, which results in a simpler structure. The commit also changes
`StringReader::advance_token` so it returns an `Option<Token>`,
simplifying the the empty input case.
`TokenTreesReader` wraps a `StringReader`, but the `into_token_trees`
function obscures this. This commit moves to a more straightforward
control flow.
The spacing computation is done in two parts. In the first part
`next_token` and `bump` use `Spacing::Alone` to mean "preceded by
whitespace" and `Spacing::Joint` to mean the opposite. In the second
part `parse_token_tree_other` then adjusts the `spacing` value to mean
the usual thing (i.e. "is the following token joinable punctuation?").
This shift in meaning is very confusing and it took me some time to
understand what was going on.
This commit changes the first part to use a bool, and adds some
comments, which makes things much clearer.
Clean up (sub)diagnostic derives
The biggest chunk of this is unifying the parsing of subdiagnostic attributes (`#[error]`, `#[suggestion(...)]`, `#[label(...)]`, etc) between `Subdiagnostic` and `Diagnostic` type attributes as well as `Diagnostic` field attributes.
It also improves a number of proc macro diagnostics.
Waiting for #101558.
Use function pointers instead of macro-unrolled loops in rustc_query_impl
By making these standalone functions, we
a) allow making them extensible in the future with a new `QueryStruct`
b) greatly decrease the amount of code in each individual function, avoiding exponential blowup in llvm
Helps with https://github.com/rust-lang/rust/issues/96524. Based on https://github.com/rust-lang/rust/pull/101173; only the last commit is relevant.
r? `@cjgillot`
`parse_token_tree` is basically a match with four arms: `Eof`,
`OpenDelim`, `CloseDelim`, and "other". It has two call sites, and at
each call site one of the arms is unreachable. It's also not inlined.
This commit removes `parse_token_tree` by splitting it into four
functions and inlining them. This avoids some repeated conditional
tests and also some non-inlined function calls on the hot path.
Neither require nor imply lifetime bounds on opaque type for well formedness
The actual hidden type can live arbitrarily longer than any individual lifetime and arbitrarily shorter than all but one of the lifetimes.
fixes#86218fixes#84305
This is a **breaking change** but it is a necessary soundness fix
These benches benchmark rust langauge features and not the compiler,
so they seem to be in the wrong place here. They also all take <1ns,
making them pretty useless. Looking at their git history, they just
seem to have been carried around for many, many years. This commit
ends their journey.
By making these standalone functions, we
a) allow making them extensible in the future with a new `QueryStruct`
b) greatly decrease the amount of code in each individual function, avoiding exponential blowup in llvm
Rollup of 8 pull requests
Successful merges:
- #98111 (Clarify `[T]::select_nth_unstable*` return values)
- #101431 (Look at move place's type when suggesting mutable reborrow)
- #101800 (Constify slice.split_at_mut(_unchecked))
- #101997 (Remove support for legacy PM)
- #102194 (Note the type when unable to drop values in compile time)
- #102200 (Constify Default impl's for Arrays and Tuples.)
- #102245 (Constify cmp_min_max_by.)
- #102259 (Type-annotate and simplify documentation of Option::unwrap_or_default)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove support for legacy PM
This removes support for optimizing with LLVM's legacy pass manager, as well as the unstable `-Znew-llvm-pass-manager` option. We have been defaulting to the new PM since LLVM 13 (except for s390x that waited for 14), and LLVM 15 removed support altogether. The only place we still use the legacy PM is for writing the output file, just like `llc` does.
cc #74705
r? ``@nikic``
Look at move place's type when suggesting mutable reborrow
Not sure why we are looking at the use site's ty instead of the move site's ty in order to suggest reborrowing the move site, but it was suppressing a perfectly valid reborrow suggestion.
r? `@estebank` who i think touched this last in 520461f1fb, though that was quite a while ago so feel free to reassign.
Don't drop parent substs when we have no generic parameters in `create_substs_for_ast_path`
This bug is being shadowed by an explicit check for `generics.params.is_empty()` in the only parent caller that could trigger it (`create_substs_for_associated_item`). I triggered it on another branch where I'm messing around with astconv stuff.
Also, the second commit simplifies `create_substs_for_associated_item`. Removing that explicit check I mentioned above^ and also the special case call to `Astconv::prohibit_generics` causes the UI test `src/test/ui/structs/struct-path-associated-type.stderr` to change, but I think that it's clearer now. The suggestion to remove the generics is actually useful.
Resolve async fn signature even without body (e.g., in trait)
Fixes#102138
This "bail if no body" behavior was introduced in #69539 to fix#69401, but that ICE does not reproduce any more. The error message changes a bit, but that's all, and I don't think it's a particularly diagnostic bad regression.
implied_bounds: deal with inference vars
fixes#101951
while computing implied bounds for `<<T as ConstructionFirm>::Builder as BuilderFn<'_>>::Output` normalization replaces a projection with an inference var (adding a `Projection` obligation). Until we prove that obligation, this inference var remains unknown, which caused us to miss an implied bound necessary to prove that the unnormalized projection from the trait method signature is wf.
r? types
fix a ui test
use `into`
fix clippy ui test
fix a run-make-fulldeps test
implement `IntoQueryParam<DefId>` for `OwnerId`
use `OwnerId` for more queries
change the type of `ParentOwnerIterator::Item` to `(OwnerId, OwnerNode)`
resolve: Set effective visibilities for imports more precisely
Instead of setting them for all primary and additional IDs of the import, only set them for the binding's true ID.
Always print '_, even for erased lifetimes.
Explicit lifetime arguments are now the recommended syntax in rust 2018 and rust 2021. This PR applies this discipline to rustc itself.
Since `len` and `is_empty` are not const stable yet, this also
creates a new feature for them since they previously used the same
`const_btree_new` feature.
Introduce mir::Unevaluated
Previously the distinction between unevaluated constants in the type-system and in mir was not explicit and a little confusing. Probably better to introduce its own type for that.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #100734 (Split out async_fn_in_trait into a separate feature)
- #101664 (Note if mismatched types have a similar name)
- #101815 (Migrated the rustc_passes annotation without effect diagnostic infrastructure)
- #102042 (Distribute rust-docs-json via rustup.)
- #102066 (rustdoc: remove unnecessary `max-width` on headers)
- #102095 (Deduplicate two functions that would soon have been three)
- #102104 (Set 'exec-env:RUST_BACKTRACE=0' in const-eval-select tests)
- #102112 (Allow full relro on powerpc64-unknown-linux-gnu)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Improve the help message for an invalid calling convention
Fixes https://github.com/rust-lang/rust/issues/93601
I mostly followed the suggestions of `@nagisa` in that issue, ~~however, I wasn't sure how to check stability for the suggestion of "Do not suggest CCs that cannot be used due to them being unstable and feature not being enabled", so I did not implement that point.~~
I haven't contributed to rustc much, please feel free to point out suggestions! For example, the `.map(|s| Symbol::intern(s)).collect::<Vec<_>>()` seems pretty gross performance-wise, but maybe that's OK in error reporting code.
Allow full relro on powerpc64-unknown-linux-gnu
This was previously limited to partial relro, citing issues on RHEL6,
but that's no longer a supported platform since #95026. We have long
been enabling full relro in RHEL7's own Rust builds for ppc64, without
trouble, so it should be fine to drop this workaround.
Migrated the rustc_passes annotation without effect diagnostic infrastructure
Small change to move the validation for annotations to the new diagnostic infrastructure.
Note if mismatched types have a similar name
If users get a type error between similarly named types, it will point out that these are actually different types, and where they were defined.
Split out async_fn_in_trait into a separate feature
PR #101224 added support for async fn in trait desuraging behind the `return_position_impl_trait_in_trait` feature.
Split this out so that it's behind its own feature gate, since async fn in trait doesn't need to follow the same stabilization schedule.
Const unification is already infallible, remove the error handling logic
r? `@lcnr`
is this expected to be used in the future? Right now it is dead code.
Inline SyntaxContext in both encoded span representation.
The current interned representation for spans does not use the `ctxt_or_zero: u16` field. This PR proposes to use this field to store the `SyntaxContext` of the interned span instead. When `ctxt_or_zero` and the interned span's `ctxt` don't match, the inlined one takes precedence.
This allows to implement `Span::ctxt` and `Span::with_ctxt` with much less probability to access the interner. Those functions are used a lot for hygiene, so this may be worth it.
Rollup of 8 pull requests
Successful merges:
- #101598 (Update rustc's information on Android's sanitizers)
- #102036 (Remove use of `io::ErrorKind::Other` in std)
- #102037 (Make cycle errors recoverable)
- #102069 (Skip `Equate` relation in `handle_opaque_type`)
- #102076 (rustc_transmute: fix big-endian discriminants)
- #102107 (Add missing space between notable trait tooltip and where clause)
- #102119 (Fix a typo “pararmeter” in error message)
- #102131 (Added which number is computed in compute_float.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustc_transmute: fix big-endian discriminants
I noticed that some new tests were failing in Fedora on s390x only, which usually means there's a problem with big-endian, and sure enough there's a FIXME(``@jswrenn)`` for that in `rustc_transmute`. This patch implements the appropriate consideration for target endianness, rather than using native (host) endian.
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, ```@jackh726``` has said we need to be careful about overflow errors: https://github.com/rust-lang/rust/pull/91430#issuecomment-983997013
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
Helps with https://github.com/rust-lang/rust/issues/81091.
r? ```@lcnr``` cc ```@matthewjasper```
Update rustc's information on Android's sanitizers
This patch updates sanitizer support definitions for Android inside the compiler. It also adjusts the logic to make sure no pre-built sanitizer runtime libraries are emitted as these are instead provided dynamically on Android targets.
Normalize opaques w/ bound vars
First, we reenable normalization of opaque types with escaping late bound regions to fix rust-lang/miri#2433. This essentially reverts #89285.
Second, we mitigate the perf regression found in #88862 by simplifying the way that we relate (sub and eq) GeneratorWitness types.
This relies on the fact that we construct these GeneratorWitness types somewhat particularly (with all free regions found in the witness types replaced with late bound regions) -- but those bound regions really should be treated as existential regions, not universal ones. Those two facts leads me to believe that we do not need to use the full `higher_ranked_sub` machinery to relate two generator witnesses. I'm pretty confident that this is correct, but I'm glad to discuss this further.
use partition_point instead of binary_search when looking up source lines
In local benchmarks this results in 0.4% fewer cycles in a critical sequential section when compiling libcore.
PR #101224 added support for async fn in trait desuraging behind the
return_position_impl_trait_in_trait feature.
Split this out so that it's behind its own feature gate, since async fn
in trait doesn't need to follow the same stabilization schedule.
Move and rename `SessionDiagnostic` & `SessionSubdiagnostic` traits and macros
After PR #101434, we want to:
- [x] Move `SessionDiagnostic` to `rustc_errors`.
- [x] Add `emit_` methods that accept `impl SessionDiagnostic` to `Handler`.
- [x] _(optional)_ Rename trait `SessionDiagnostic` to `DiagnosticHandler`.
- [x] _(optional)_ Rename macro `SessionDiagnostic` to `DiagnosticHandler`.
- [x] Update Rustc Dev Guide and Docs to reflect these changes. https://github.com/rust-lang/rustc-dev-guide/pull/1460
Now I am having build issues getting the compiler to build when trying to rename the macro.
<details>
<summary>See diagnostics errors and context when building.</summary>
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:13:10
|
13 | #[derive(DiagnosticHandler)]
| ^^^^^^^^^^^^^^^^^ in this derive macro expansion
|
::: /Users/jhonny/.cargo/registry/src/github.com-1ecc6299db9ec823/synstructure-0.12.6/src/macros.rs:94:9
|
94 | / pub fn $derives(
95 | | i: $crate::macros::TokenStream
96 | | ) -> $crate::macros::TokenStream {
| |________________________________________- in this expansion of `#[derive(DiagnosticHandler)]`
|
note: the lint level is defined here
--> compiler/rustc_attr/src/lib.rs:10:9
|
10 | #![deny(rustc::diagnostic_outside_of_impl)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
And also this one:
```
error: diagnostics should only be created in `SessionDiagnostic`/`AddSubdiagnostic` impls
--> compiler/rustc_attr/src/session_diagnostics.rs:213:32
|
213 | let mut diag = handler.struct_span_err_with_code(
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
> **Note**
> Can't find where this message is coming from, because you can see in [this experimental branch](https://github.com/JhonnyBillM/rust/tree/experimental/trying-to-rename-session-diagnostic-macro) that I updated all errors and diags to say:
> error: diagnostics should only be created in **`DiagnosticHandler`**/`AddSubdiagnostic` impls
> and not:
> error: diagnostics should only be created in **`SessionDiagnostic`**/`AddSubdiagnostic` impls
</details>
I tried building the compiler in different ways (playing with the stages etc), but nothing worked.
## Question
**Do we need to build or do something different when renaming a macro and identifiers?**
For context, see experimental commit f2193a98b4 where the macro and symbols are renamed, but it doesn't compile.
This was previously limited to partial relro, citing issues on RHEL6,
but that's no longer a supported platform since #95026. We have long
been enabling full relro in RHEL7's own Rust builds for ppc64, without
trouble, so it should be fine to drop this workaround.
FIX - ambiguous Diagnostic link in docs
UPDATE - rename diagnostic_items to IntoDiagnostic and AddToDiagnostic
[Gardening] FIX - formatting via `x fmt`
FIX - rebase conflicts. NOTE: Confirm wheather or not we want to handle TargetDataLayoutErrorsWrapper this way
DELETE - unneeded allow attributes in Handler method
FIX - broken test
FIX - Rebase conflict
UPDATE - rename residual _SessionDiagnostic and fix LintDiag link
Add armv5te-none-eabi and thumbv5te-none-eabi targets
Creates two new Tier 3 targets, `armv5te-none-eabi` and `thumbv5te-none-eabi`. They are for the same target architecture (armv5te), but one defaults to the A32 instruction set and the other defaults to T32. Based on the existing `armv4t-none-eabi` and `thumbv4t-none-eabi` targets.
My particular use case for these targets is Nintendo DS homebrew, but they should be usable for any armv5te system.
Going through the Tier 3 target policy:
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
That will be me.
> Targets must use naming consistent with any existing targets.
Naming is consistent with previous targets.
>> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility.
No ambiguity here.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
Doesn't create any legal issues.
>> The target must not introduce license incompatibilities.
This doesn't introduce any new licenses.
>> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Yep.
>> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
No new license requirements.
>> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries.
Everything this uses is FOSS, no proprietary required.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
OK.
>> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
OK.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
This is a bare-metal target with only support for `core` (and `alloc`, if the user provides an allocator).
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
Documentation has been added.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@)` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
OK.
> Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
OK.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
This doesn't break any other targets.
>> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
No unnecessary unconditional features here.
a fn pointer doesn't implement `Fn`/`FnMut`/`FnOnce` if its return type isn't sized
I stumbled upon #83915 which hasn't received much attention recently, and I wanted to revive it since this is one existing soundness hole that seems pretty easy to fix.
I'm not actually sure that the [alternative approach described here](https://github.com/rust-lang/rust/pull/83915#issuecomment-823643322) is sufficient, given the `src/test/ui/function-pointer/unsized-ret.rs` example I provided below. Rebasing the branch mentioned in that comment and testing that UI test, it seems that we actually end up only observing that `str: !Sized` during monomorphization, whereupon we ICE. Even if we were to fix that ICE, ideally we'd be raising an error that a fn pointer is being used badly during _typecheck_ instead of monomorphization, hence adapting the original approach in #83915.
I am happy to close this if people would prefer we rebase the original PR and land that -- I am partly opening to be annoying and get people thinking about this unsoundness again ❤️😸
cc: `@estebank` and `@nikomatsakis`
r? types
Here's a link to the thread: https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/PR.20.2383915/near/235421351 for more context.
It's now much more like the `-Zhir-stats` output.
- Each line is preceded with `meta-stats`, which makes the provenance
clearer and allows filtering of the output.
- Sections are now sorted in reverse order of size.
- Column headings avoid the need to repeat the word "bytes" on every line.
- Long numbers now have `_` separators for easier reading.
- Consistent use of '-' within section labels, rather than a mix of '-',
'_', and ' '.
The code itself is shorter and easier to read thanks to:
- the `stat` macro, which encapsulates each section's encoding, avoids
some boilerplate, and removes the need for some low-value comments;
- the `stats` vector, which replaces dozens of local variables.
This patch updates sanitizier support definitions for Android inside the
compiler. It also adjusts the logic to make sure no pre-built sanitizer
runtime libraries are emitted as these are instead provided dynamically
on Android targets.
Improve error for when query is unsupported by crate
This is an improvement to the error message mentioned on #101666. It seems like a good idea to also add [this link to the rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/query.html), if explaining the query system in detail is a concern here, but I'm unsure if there is any restrictions on adding links to error messages.
