Make lint diagnostics responsible for providing their primary span

[fmease]

Summary and Rustc-Dev-Facing Changes

Instead of passing the primary span of lint diagnostics separately — namely to the functions tcx.emit_span_lint and tcx.emit_node_span_lint —, make lint diagnostics responsible for “storing” (providing) their span. I've removed the two aforementioned methods. You are now expected to use tcx.emit_lint and tcx.emit_node_lint respectively and to provide the primary span when deriving LintDiagnostic (via #[primary_span]) / implementing LintDiagnostic manually (via LintDiagnostic::span).

Note

FIXME(fmease): Mention how early lints are handled.

Motivation

Making the general format of #[derive(LintDiagnostic)] identical to #[derive(Diagnostic)]. I bet this has lead to slight confusion or annoyances before. Moreover, it enables deriving both traits at once (see #125169 for the motivation).

Approach

As outlined in #125169 (comment), the naïve approach of doing the same as Diagnostic doesn't work for LintDiagnostic, i.e., setting the primary span with Diag::span inside decorate_lint (that's into_diag for Diagnostic) because lint_level (lint_level_impl) needs access to the primary spans before decorating the Diag to be able to filter out some lints (namely if they come from an external macro) etc.

Therefore, I had to introduce a new method to LintDiagnostic: fn span(&self) -> Option<MultiSpan> (similar to the existing method LintDiagnostic::msg).

Commits

1. The 1st commit addresses #125169 (comment). It contains the necessary changes to the linting APIs. It doesn't build on its own due to the removed APIs. Split out for easier reviewing.
2. The 2nd commit updates all existing lint diagnostics to use the new APIs. Most of them are mindless, monotonous, obvious changes. Some changes are slightly more involved out of necessity. I've verified (partly programmatically, partly manually) that all lint diags that used to have a primary span still have a primary span.
3. The 3rd commit updates the fulldeps UI tests that exercise the (lint) diagnostic API
4. The 4th commit fixes #125169. I've only deduplicated the lint diagnostic structs mentioned in the issue and haven't gone looking for other structs that may benefit from deriving both Diagnostic and LintDiagnostic because I didn't have the time to do so yet.

Meta

Fixes #125169.

I'll submit a rustc-dev-guide PR later.
I hope this doesn't need an MCP, it's pretty straight forward.

cc @davidtwco
r? @nnethercote or anyone on compiler who has the energy to review 82 files

[fmease]

@bors p=1 prone to bitrot

[rustbot]

rustc_macros::diagnostics was changed

cc @davidtwco, @compiler-errors, @TaKO8Ki

Some changes occurred in exhaustiveness checking

cc @Nadrieril

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[Xiretza]

I foresee lots of merge conflicts with #124417 :/

[fmease]

@Xiretza Happy to block this PR on yours and do the rebasing myself here.

[bors]

☔ The latest upstream changes (presumably #125077) made this pull request unmergeable. Please resolve the merge conflicts.

[nnethercote]

@Xiretza Happy to block this PR on yours and do the rebasing myself here.

@fmease: this seems fine to me but I guess you're still waiting on this.

[davidtwco]

This looks good to me, r=me once you're ready to see this merged

[fmease]

@bors try @rust-timer queue

[bors]

⌛ Trying commit b22eadf with merge 9de008a...

[fmease]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 775527e with merge 6932f95...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6932f95 (6932f95f7e07a6e1df8a6e7bc81854d5eaab79c6)

[rust-timer]

Finished benchmarking commit (6932f95): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-0.6%	[-1.6%, -0.1%]	3
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Max RSS (memory usage)

Results (primary 2.1%, secondary 3.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.1%	[1.3%, 2.8%]	2
Regressions ❌ (secondary)	3.2%	[2.9%, 3.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[1.3%, 2.8%]	2

Cycles

Results (primary -2.4%, secondary 3.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.4%	[-2.4%, -2.4%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 785.158s -> 785.364s (0.03%)
Artifact size: 333.66 MiB -> 333.68 MiB (0.01%)

[nnethercote]

David gave a soft approval for an earlier version of this, so it makes sense to officially hand it over now that it seems close to being ready.

r? @davidtwco

[fmease]

Yesterday I coincidentally stumbled upon this Zulip post from 2024-09-25 which essentially declares the current diagnostic translation effort (#100717) unfruitful and unmaintained. While I only read this post yesterday, I have been aware of this fact for some time.

Therefore I don't want to burden davidtwco with re-reviewing >1000 lines and I'm also fine with closing this PR.

Of course, not a lot has changed. It's essentially a rebase from a 5 month old master. I stalled the rebase until now because I knew that this approach (of making lint diagnostics responsible or providing their primary span) does not scale to early (buffered) lints. I came to realize that when reviewing PR #124417 (which made early lints translatable) and implementing PR #125410 (which won back some of the perf regressions caused by the former).

You say it doesn't scale to early (buffered) lints, so how did you succeed in rebasing then while keeping perf in check? Well, I've cheated a little bit. The statement "lints diagnostics are responsible for providing their primary span" now only holds for non-early lints. The early lint diagnostics don't provide a #[primary_span] / return None for LintDiagnostic::span(&self) -> Option<MultiSpan> with the hidden assumption/knowledge¹ that it's supplied separately in opt_span_lint_with_diagnostics from BufferedEarlyLint.span.

For perf reasons, we can't eagerly "lower" BuiltinLintDiag to lint diagnostics ("impl LintDiagnostic") inside opt_span_lint_with_diagnostics via decorate_lint². However, only if we lower eagerly, we can truly make early lint diagnostics responsible for providing their primary span – and that's off the table. Re. perf, the lowering step is expensive and therefore we delay this step as far back as possible. Namely we don't want to lower lint diagnostics that end up not getting emitted (due to lint levels). We achieve this by letting lint_level decide … which takes a Span that is used in its decision process! We need the primary span(s) before lowering to lint diagnostics, therefore lint diagnostics cannot possibly provide their primary span!

This creates a divide between early and late LintDiagnostics which is unacceptable in my opinion. I wanted to bring {,Lint}Diagnostic closer together for ease of understanding and use. This simply doesn't work if LintDiagnostic itself is divided. As such, I no longer believe in this PR.

Footnotes

1. Well, I did add comments in the LintDiagnostic::span cases but not in the #[derive(LintDiagnostic)] ones (there are simply too many). ↩

2. See the merged commit https://github.com/rust-lang/rust/pull/125410/commits/37bf2d2dabdbdce9473b0fed1708fcbf31ba9c1a which reverted this. ↩