Clean up `TyCtxt::needs_crate_hash` usage and rename it to `needs_hir_hash`.
While reviewing `crate_hash` query usage for https://github.com/rust-lang/rust/pull/155871, the `needs_crate_hash` function turned out to be the cause of unnecessary calls to the query. The `needs_crate_hash` name is easy to mistake for the functionality of "needs the crate_hash query". This PR removes the usage of `needs_crate_hash` where it was not appropriate and renames the function to `needs_hir_hash` which better reflects its functionality.
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
Exactly as the comment on the `crate_hash` field of `Linker` says, that
field is only used when incremental compilation is enabled.
`needs_crate_hash` returns true in some other cases too.
Move `feature*` methods from `parse` mod to `errors` mod.
As the FIXME comment says, these no longer use `ParseSess` and so the `parse` mod is not a good place for them. The `errors` mod is a better home.
r? @TaKO8Ki
Catch unwinds from the global ctxt callback to complete queries profiling data in more cases
The driver/compiler interface provides multiple callbacks, and we sometimes catch unwinds to flush diagnostics, ensure ICEs appear, and so on even when fatal errors occur.
When these panics happen, we don't `finish` the `TyCtxt`, and there's a fixme about that. Unfortunately this is where we also allocate the self-profile strings: query events for example start as virtual and are turned into real strings by this finalization process; they are _invalid_ without this step. When fatal errors happen, the in-flight query name will be `<unknown>`, event counts will be inaccurate, etc.
This PR catches panics from another of these callbacks, where the `TyCtxt` is available, to allow for the self-profiling data to be computed before continuing the unwinding process as before. `finish` does more things, that I don't want to introduce here.
I remember seeing this discussed in GH issues in the past, but can't find any open ones now. It may also have been only mentioned while trying to profile existing slowness issues. I stumbled upon this again recently when looking into `tests/ui/try-trait/deep-try-chain-issue-153583.rs`, where the slowest query is `<unknown>`.
```
> rm *.mm_profdata ; rustc +nightly -Zself-profile tests/ui/try-trait/deep-try-chain-issue-153583.rs ; summarize summarize *.mm_profdata | head -n 5
error[E0277]: the `?` operator can only be applied to values that implement `Try`
--> tests/ui/try-trait/deep-try-chain-issue-153583.rs:6:5
|
6 | 0?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????...
| ^^ the `?` operator cannot be applied to type `{integer}`
|
= help: the nightly-only, unstable trait `Try` is not implemented for `{integer}`
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0277`.
+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item | Self time | % of total time | Time | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| <unknown> | 1.55s | 99.416 | 3.21s | 15230 |
+------------------------------------------------------+-----------+-----------------+----------+------------+
```
This PR fixes that case at least. In general, it should fix the invalid profiling records for fatal errors happening while a query is running.
```
+------------------------------------------------------+-----------+-----------------+----------+------------+
| Item | Self time | % of total time | Time | Item count |
+------------------------------------------------------+-----------+-----------------+----------+------------+
| typeck_root | 5.04s | 95.588 | 5.08s | 1 |
+------------------------------------------------------+-----------+-----------------+----------+------------+
```
r? @bjorn3
fatal errors currently abort the compiler process without allocating the self-profile
strings: query events aren't always correctly recorded, and will show up as <unknown>
in the data.
catching the unwinding panic allows us to finalize the self-profiling process correctly
before continuing unwinding as before.
Remove attribute parsing `Stage`
I discovered that it is surprisingly easy to remove the concept of `Stage` in the attribute parsers, imo this makes the code a lot cleaner.
r? @jdonszelmann
cc @mejrs @Bryntet
`ParseSess` is separate from, but sits within, `Session`. The separation
is because there are some places (e.g. `Parser` methods) where
`ParseSess` is available but `Session` is not.
However, `ParseSess` has four fields that are only accessed from places
where `Session` is also available. This commit moves those fields to
`Session`. This means that `ParseSess` only contains the fields it
genuinely needs, and various `sess.psess.foo` occurrences are reduced to
`sess.foo`.
Create a new `SharedContext::emit_dyn_lint_with_sess` method to simplify code when `Session` is not needed
Remove crate name from `UnexpectedCfgCargoMacroHelp`
This is a callback used to track otherwise untracked state. It was added
in #116731 for Clippy. (It was originally named `hash_untracked_state`,
and examples in the rustc-dev-guide still use that name.) The
`StableHasher` argument is unused, and probably has never been used.
There is a FIXME comment pointing this out, which was added more than a
year ago.
This commit removes the `StableHasher` callback argument. This also
removes the need for `Options::untracked_state_hash`.
Most diagnostic types are only used within their own crate, and so have
a `pub(crate)` visibility. We have some diagnostic types that are
unnecessarily `pub`. This is bad because (a) information hiding, and (b)
if a `pub(crate)` type becomes unused the compiler will warn but it
won't warn for a `pub` type.
This commit eliminates unnecessary `pub` visibilities for some
diagnostic types, and also some related things due to knock-on effects.
(I found these types with some ad hoc use of `grep`.)
Implement `-Z allow-partial-mitigations` (RFC 3855)
This implements `-Z allow-partial-mitigations` as an unstable option, currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo` rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a better policy is possible (bikeshed).
r? @rcvalle
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#152901 (Introduce a `#[diagnostic::on_unknown]` attribute)
- rust-lang/rust#155078 (Reject dangling attributes in where clauses)
- rust-lang/rust#154449 (Invert dependency between `rustc_errors` and `rustc_abi`.)
- rust-lang/rust#154646 (Add suggestion to `.to_owned()` used on `Cow` when borrowing)
- rust-lang/rust#154993 (compiletest: pass -Zunstable-options for unpretty and no-codegen paths)
- rust-lang/rust#155097 (Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`)
Make `rustc_attr_parsing::SharedContext::emit_lint` take a `MultiSpan` instead of a `Span`
I'll likely need it for https://github.com/rust-lang/rust/pull/153721 to allow emitting the lint on one attribute at a time instead of each of the wrong values.
r? @JonathanBrouwer
Introduce a `#[diagnostic::on_unknown]` attribute
This PR introduces a `#[diagnostic::on_unknown]` attribute that allows crate authors to customize the error messages emitted by unresolved imports. The main usecase for this is using this attribute as part of a proc macro that expects a certain external module structure to exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel, that expect to refer to a `tabe` module. That is done either implicitly (via the name of the type with the derive) or explicitly by the user. This attribute would allow us to improve the error message in both cases:
* For the implicit case we could explicity call out our assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the user why this is happening and what they should look for to fix the problem (be more explicit about certain diesel specific assumptions of the module structure)
I assume that similar use-cases exist for other proc-macros as well, therefore I decided to put in the work implementing this new attribute. I would also assume that this is likely not useful for std-lib internal usage.
related rust-lang/rust#152900 and rust-lang/rust#128674
This PR introduces a `#[diagnostic::on_unknown_item]` attribute that
allows crate authors to customize the error messages emitted by
unresolved imports. The main usecase for this is using this attribute as
part of a proc macro that expects a certain external module structure to
exist or certain dependencies to be there.
For me personally the motivating use-case are several derives in diesel,
that expect to refer to a `tabe` module. That is done either
implicitly (via the name of the type with the derive) or explicitly by
the user. This attribute would allow us to improve the error message in
both cases:
* For the implicit case we could explicity call out our
assumptions (turning the name into lower case, adding an `s` in the end)
+ point to the explicit variant as alternative
* For the explicit variant we would add additional notes to tell the
user why this is happening and what they should look for to fix the
problem (be more explicit about certain diesel specific assumptions of
the module structure)
I assume that similar use-cases exist for other proc-macros as well,
therefore I decided to put in the work implementing this new attribute.
I would also assume that this is likely not useful for std-lib internal
usage.
Break a single query cycle in the deadlock handler
This simplifies the query cycle handling by only breaking a single query cycle each time the deadlock handler is called.
delegation: fix cycles during delayed lowering
This PR forces lowering of delayed owners after `hir_crate_items`, as some diagnostics use `hir_crate_items` which results in query cycle which is then hangs calling `def_path_str` again and again. Fixesrust-lang/rust#154169. Part of rust-lang/rust#118212.
r? @petrochenkov
This implements `-Z allow-partial-mitigations` as an unstable option,
currently with support for control-flow-guard and stack-protector.
As a difference from the RFC, we have `-Z allow-partial-mitigations=!foo`
rather than `-Z deny-partial-mitigations=foo`, since I couldn't find an easy
way to have an allow/deny pair of flags where the latter flag wins.
To allow for stabilization, this is only enabled starting from the next edition. Maybe a
better policy is possible (bikeshed).
`rustc_hir_analysis` depends on `rustc_lint` in just a single function:
`emit_delayed_lint`, which is used by the
"emit_ast_lowering_delayed_lints" checking section within
`rustc_hir_analysis::check_crate`.
This commit moves that function and section to out of
`rustc_hir_analysis::check_crate`, into `rustc_interface`, eliminating
the dependency. This seems reasonable because the delayed lint errors
aren't really related to HIR analysis. They were in there just because
HIR analysis follows AST lowering.
This means `rustc_hir_analysis` and `rustc_lint` can both start
compiling as soon as `rustc_trait_selection` finishes. This also changes
the error order in one test, which doesn't matter.
The commit also changes `emit_delayed_lint` to `emit_delayed_lints`,
factoring out some code duplicated in rustdoc.
Simplify find_attr! for HirId usage
Add a `HasAttrs<'tcx, Tcx>` trait to `rustc_hir` that allows `find_attr!` to accept `DefId`, `LocalDefId`, `OwnerId`, and `HirId` directly, instead of requiring callers to manually fetch the attribute slice first.
Before:
`find_attr!(tcx.hir_attrs(hir_id), SomeAttr)`
After:
`find_attr!(tcx, hir_id, SomeAttr)`
The trait is defined in `rustc_hir` with a generic `Tcx` parameter to avoid a dependency cycle (`rustc_hir` cannot depend on `rustc_middle`). The four concrete impls for `TyCtxt` are in `rustc_middle`.
Fixes https://github.com/rust-lang/rust/issues/153103
Guillaume Gomez