[perf] Delay the construction of early lint diag structs
Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.
See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc671, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
With the removal of `LintDiagnostic::msg` / the `msg` param from
lint diag APIs, primary messages for lint diags are always constructed
lazily inside decorator fns rendering this wrapper type unused / useless.
* instead simply set the primary message inside the lint decorator functions
* it used to be this way before [#]101986 which introduced `msg` to prevent
good path delayed bugs (which no longer exist) from firing under certain
circumstances when lints were suppressed / silenced
* this is no longer necessary for various reasons I presume
* it shaves off complexity and makes further changes easier to implement
There are a few common abbreviations like `use rustc_ast as ast` and
`use rust_hir as hir` for names that are used a lot. But there are also
some cases where a crate is renamed just once in the whole codebase, and
that ends up making things harder to read rather than easier. This
commit removes them.
Remove many `#[macro_use] extern crate foo` items
This requires the addition of more `use` items, which often make the code more verbose. But they also make the code easier to read, because `#[macro_use]` obscures where macros are defined.
r? `@fee1-dead`
Fix substitution parts having a shifted underline in some cases
If two suggestions parts are side by side, the underline's offset:
(WIP PR as an example, not yet pushed)
```
error: expected a pattern, found an expression
--> ./main.rs:4:9
|
4 | 1 + 2 => 3
| ^^^^^ arbitrary expressions are not allowed in patterns
|
help: check the value in an arm guard
|
4 | n if n == 1 + 2 => 3
| ~ +++++++++++++
```
The emitter didn't take into account that the string had shrunk/grown if two substitution parts were side-by-side (surprisingly, there was only one case in the ui testsuite.)
```
help: check the value in an arm guard
|
4 | n if n == 1 + 2 => 3
| ~ +++++++++++++
```
``@rustbot`` label +A-suggestion-diagnostics
Check `x86_64` size assertions on `aarch64`, too
(Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Checking.20size.20assertions.20on.20aarch64.3F)
Currently the compiler has around 30 sets of `static_assert_size!` for various size-critical data structures (e.g. various IR nodes), guarded by `#[cfg(all(target_arch = "x86_64", target_pointer_width = "64"))]`.
(Presumably this cfg avoids having to maintain separate size values for 32-bit targets and unusual 64-bit targets. Apparently it may have been necessary before the i128/u128 alignment changes, too.)
This is slightly incovenient for people on aarch64 workstations (e.g. Macs), because the assertions normally aren't checked until we push to a PR. So this PR adds `aarch64` to the `#[cfg(..)]` guarding all of those assertions in the compiler.
---
Implemented with a simple find/replace. Verified by manually inspecting each `static_assert_size!` in `compiler/`, and checking that either the replacement succeeded, or adding aarch64 wouldn't have been appropriate.
Better reporting on generic argument mismatchs
This allows better reporting as per issue #116615 .
If you have a function:
```
fn foo(a: T, b: T) {}
```
and call it like so:
```
foo(1, 2.)
```
it'll give improved error reported similar to the following:
```
error[E0308]: mismatched types
--> generic-mismatch-reporting-issue-116615.rs:6:12
|
6 | foo(1, 2.);
| --- - ^^ expected integer, found floating-point number
| | |
| | expected argument `b` to be an integer because that argument needs to match the type of this parameter
| arguments to this function are incorrect
|
note: function defined here
--> generic-mismatch-reporting-issue-116615.rs:1:4
|
1 | fn foo<T>(a: T, b: T) {}
| ^^^ - ---- ----
| | | |
| | | this parameter needs to match the integer type of `a`
| | `b` needs to match the type of this parameter
| `a` and `b` all reference this parameter T
```
Open question, do we need to worry about error message translation into other languages? Not sure what the status of that is in Rust.
NB: Needs some checking over and some tests have altered that need sanity checking, but overall this is starting to get somewhere now. Will take out of draft PR status when this has been done, raising now to allow feedback at this stage, probably 90% ready.
conditionally ignore fatal diagnostic in the SilentEmitter
This change is primarily meant to allow rustfmt to ignore all diagnostics when using the `SilentEmitter`. Back in #121301 the `SilentEmitter` was shared between rustc and rustfmt. This changed rustfmt's behavior from ignoring all diagnostic to emitting fatal diagnostics, which lead to https://github.com/rust-lang/rustfmt/issues/6109.
These changes allow rustfmt to maintain its previous behaviour when using the `SilentEmitter`, while allowing rustc code to still emit fatal diagnostics.
This change is primarily meant to allow rustfmt to ignore all
diagnostics when using the `SilentEmitter`. Back in PR 121301 the
`SilentEmitter` was shared between rustc and rustfmt. This changed
rustfmt's behavior from ignoring all diagnostic to emitting fatal
diagnostics.
These changes allow rustfmt to maintain it's previous behaviour when
using the SilentEmitter, while allowing rustc code to still emit fatal
diagnostics.
- Firstly get all the information about generics matching out of the HIR
- Secondly the labelling for the function is more coherent now
- Lastly a few error message improvements
Enable creating backtraces via -Ztreat-err-as-bug when stashing errors
r? `@nnethercote`
Otherwise I can't debug stashed errors because I can't find their source
Store backtrace for `must_produce_diag`
This makes it significantly easier to debug a `must_produce_diag` ICE, since we have no other way to know where the heck the bug originates from.
Backtrace rendering kinda sucks right now since we're just printing it in the panic message; happy to apply some suggestions to make it prettier or reuse other bug printing machinery, but also don't want to iterate too much on the rendering since this really is just for debug purposes.
r? nnethercote
Rework `untranslatable_diagnostic` lint
Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.
r? ``@davidtwco``
Prior to the previous commit, `#[rust_lint_diagnostics]` attributes
could only be used on methods with an `impl Into<{D,Subd}iagMessage>`
parameter. But there are many other nearby diagnostic methods (e.g.
`Diag::span`) that don't take such a parameter and should have the
attribute.
This commit adds the missing attribute to these `Diag` methods. This
requires adding some missing
`#[allow(rustc::diagnostic_outside_of_impl)]` markers at call sites to
these methods.
From `impl Into<DiagnosticMessage>` to `impl Into<Cow<'static, str>>`.
Because these functions don't produce user-facing output and we don't
want their strings to be translated.
Note that `self.suppressed_expected_diag` is no longer set for
`ForceWarning`, which is good. Nor is `TRACK_DIAGNOSTIC` called for
`Allow`, which is also good.
It results in a tiny bit of duplication (another
`self.treat_next_err_as_bug()` condition) but I think it's worth it to
get more code into the main `match`.
By just emitting them immediately, because it does happen in practice,
when errors are downgraded to delayed bugs.
We already had one case in `lint.rs` where we handled this at the
callsite. This commit changes things so it's handled within
`stash_diagnostic` instead, because #121812 identified a second case,
and it's possible there are more.
Fixes#121812.
Emitter cleanups
Some cleanups I made when reading emitter code. In particular, `HumanEmitter` and `JsonEmitter` have gone from three constructors to one.
r? `@oli-obk`
Count stashed errors again
Stashed diagnostics are such a pain. Their "might be emitted, might not" semantics messes with lots of things.
#120828 and #121206 made some big changes to how they work, improving some things, but still leaving some problems, as seen by the issues caused by #121206. This PR aims to fix all of them by restricting them in a way that eliminates the "might be emitted, might not" semantics while still allowing 98% of their benefit. Details in the individual commit logs.
r? `@oli-obk`
And likewise with `ColorConfig::suggests_using_colors`. They both have a
single call site. And note that `BufWriter::supports_color()` always
returns false, which enables a small bit of constant folding along the
way.
In practice, 'a and 'b and 'c are always the same. This change makes
`UnusedExterns` more like `ArtifactNotification`, which uses a single
lifetime 'a in multiple ways.
I removed it in #121206 because I thought thought it wasn't necessary.
But then I had to add an `emit_stashed_diagnostics` call elsewhere in
rustfmt to avoid the assertion failure (which took two attempts to get
right, #121487 and #121615), and now there's an assertion failure in
clippy as well (https://github.com/rust-lang/rust-clippy/issues/12364).
So this commit just reinstates the call in `DiagCtxtInner::drop`. It
also reverts the rustfmt changes from #121487 and #121615, though it
keeps the tests added for those PRs.
Stashed errors used to be counted as errors, but could then be
cancelled, leading to `ErrorGuaranteed` soundness holes. #120828 changed
that, closing the soundness hole. But it introduced other difficulties
because you sometimes have to account for pending stashed errors when
making decisions about whether errors have occured/will occur and it's
easy to overlook these.
This commit aims for a middle ground.
- Stashed errors (not warnings) are counted immediately as emitted
errors, avoiding the possibility of forgetting to consider them.
- The ability to cancel (or downgrade) stashed errors is eliminated, by
disallowing the use of `steal_diagnostic` with errors, and introducing
the more restrictive methods `try_steal_{modify,replace}_and_emit_err`
that can be used instead.
Other things:
- `DiagnosticBuilder::stash` and `DiagCtxt::stash_diagnostic` now both
return `Option<ErrorGuaranteed>`, which enables the removal of two
`delayed_bug` calls and one `Ty::new_error_with_message` call. This is
possible because we store error guarantees in
`DiagCtxt::stashed_diagnostics`.
- Storing the guarantees also saves us having to maintain a counter.
- Calls to the `stashed_err_count` method are no longer necessary
alongside calls to `has_errors`, which is a nice simplification, and
eliminates two more `span_delayed_bug` calls and one FIXME comment.
- Tests are added for three of the four fixed PRs mentioned below.
- `issue-121108.rs`'s output improved slightly, omitting a non-useful
error message.
Fixes#121451.
Fixes#121477.
Fixes#121504.
Fixes#121508.
This commit:
- Moves the ICE file create/open outside the loop. (Redoing it on every
loop iteration works, but is really weird.)
- Moves the explanatory note emission above the loop, which removes the
need for the `enumerate` call.
- Introduces a `decorate` local.
Note the change of the `D` to `d`, to match all the other names that
have `Subdiag` in them, such as `SubdiagnosticMessage` and
`derive(Subdiagnostic)`.
