Migration of LintDiagnostic - part 5

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️

[GuillaumeGomez]

View all comments

Part of #153099.

With this, rust_lint is finally done, although the change of API of decorate_builtin_lint impacted a few other crates, although minimal, still needed to be mentioned.

r? @JonathanBrouwer

[rustbot]

JonathanBrouwer is currently at their maximum review capacity.
They may take a while to respond.

[JonathanBrouwer]

@bors try @rust-timer queue

[GuillaumeGomez]

Simplified EmitDiag and removed duplicated code. Keeping the last item for after this PR is merged as it's already big enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0c55ed2 (0c55ed2450ed4df93bd1cbfbca3f3e31a391a171, parent: 25396cf54981afd1fa5a7406658b45033106a0d3)

[rust-timer]

Finished benchmarking commit (0c55ed2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[0.5%, 3.8%]	13
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

Results (primary -6.1%, secondary 2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.0%	[3.7%, 4.7%]	3
Improvements ✅ (primary)	-6.1%	[-6.1%, -6.1%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-6.1%	[-6.1%, -6.1%]	1

Binary size

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

Bootstrap: 481.72s -> 480.975s (-0.15%)
Artifact size: 395.60 MiB -> 395.80 MiB (0.05%)

[JonathanBrouwer]

If not too annoying I'd like to see the perf regression fixed as well

[JonathanBrouwer]

@bors r+ rollup=never
I've spent a few hours locally debugging this perf regression, it seems to be caused by decorate_builtin_lint being called if the lint level is Allow, whereas previously it would quick-exit before this already. I think this is hard to prevent, and the regression is small enough (2% on a secondary test that literally does nothing other than emit allowed lints) that it's fine to accept it.

I've added taking a further look at this to the TODO list of the tracking issue, I have some ideas but don't have time right away to try those out

[rust-bors]

📌 Commit 3bc1950 has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

IIUC this PR basically undoes my PR #125410 (its perf vs this PR's perf). It's very intentional that these were decorated lazily.

Why can't the decorating keep happening lazily for decorate_builtin_lint under the new API you're working towards?

[JonathanBrouwer]

That PR's perf had effect on primary benchmarks, while this one only regresses the secondary benchmark, so it's definitely not fully undoing your work.

It's not easy because the new API we're working towards making lint_level take a impl Diagnostic for consistency with errors & warnings, which is harder to properly make lazy. I still think it's possible, one of my ideas is a custom implementation of Diagnostic for BuiltinDiag, but I'd prefer to do that in a separate PR since this one is already on the larger size.

I like perf just as much as you, and I do want to fix this, just don't think the perf regression is bad enough that it has to be done now

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JonathanBrouwer]

^ Rebased to solve merge conflicts

[JonathanBrouwer]

@bors try cancel
@bors try

[rust-bors]

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22598721349

[GuillaumeGomez]

Github doesn't allow to approve your own PR but your changes look good to me, thanks!

View changes since this review

[rust-bors]

☀️ Try build successful (CI)
Build commit: e2bd8b9 (e2bd8b9142745e8d99284919273adec4edb2d3a9, parent: 8ddf4ef064fb702fed0f3d239ec8d0bac607484e)

[rust-timer]

Finished benchmarking commit (e2bd8b9): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary 1.9%, secondary -0.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.5%	[1.7%, 3.4%]	4
Regressions ❌ (secondary)	3.2%	[3.2%, 3.2%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-1.8%	[-2.3%, -1.2%]	2
All ❌✅ (primary)	1.9%	[-0.7%, 3.4%]	5

Cycles

Results (secondary 4.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.4%, 6.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 480.113s -> 479.022s (-0.23%)
Artifact size: 396.96 MiB -> 394.98 MiB (-0.50%)

[JonathanBrouwer]

@bors r+ rollup

[rust-bors]

📌 Commit 8a824ee has been approved by JonathanBrouwer

It is now in the queue for this repository.

[fmease]

Thanks a bunch for addressing the perf regression, @JonathanBrouwer 🙏❤️