perf: fold all late lint passes into one statically-combined pass

[xmakro]

Replaces clippy's per-pass late-lint dispatch (one indirect dyn vtable call per registered pass, per HIR node) with a single statically-combined late pass. This means empty default method bodies DCE away, so the surviving overrides become inlined calls behind predicted branches instead of indirect dispatch.

Benchmarked with N=10, medians:

crate	instructions	branches	branch-misses	cycles	wall
tokio	−9.1%	−13.2%	−48.2%	−21.5%	−20.9%
ripgrep	−10.3%	−14.7%	−57.4%	−27.6%	−25.9%
regex	−5.9%	−8.5%	−33.1%	−17.4%	−15.7%
syn	−9.6%	−13.8%	−56.6%	−24.2%	−22.9%
serde	−10.7%	−15.2%	−65.1%	−23.8%	−22.8%
wasmi	−6.3%	−9.2%	−60.8%	−19.6%	−18.9%

I verified diagnostics are identical for all benchmarked crates.

I also adapted cargo dev new_lint to insert new late passes correctly with the updated syntax.

changelog: none

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @samueltardieu (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 8 candidates
• 8 candidates expanded to 8 candidates
• Random selection from Jarcho, ada4a, dswij, llogiq, samueltardieu

[xmakro]

cc @blyxyas, @y21 and @flip1995 who might have comments on this approach

[samueltardieu]

r? @blyxyas
@rustbot label G-performance-project

[rustbot]

blyxyas is not on the review rotation at the moment.
They may take a while to respond.

[blyxyas]

I've verified the performance improvements, although not as pronounced as in the pull request's description, they're very much appreciable!

Thank you for this contribution!, Having so many empty bodies were a pain point and something that I wanted to optimize, but didn't know exactly how.

I'll review the PR itself now, and if everything's correct, it'll be merged.

[blyxyas]

Everything seems good, just a nit!

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[xmakro]

Thank you for the prompt review @blyxyas! I addressed your comment.

For the performance improvement, how are you benchmarking? What CPU are you running on? Did the instruction count reduction match? And what was the wall clock time reduction on your machine? I measured on AMD Ryzen 9 9950X3D (Zen 5).

Once this is merged, I can send a follow up PR to apply the same approach for the early passes.

[blyxyas]

how are you benchmarking? What CPU are you running on? Did the instruction count reduction match? And what was the wall clock time reduction on your machine?

I'm benchmarking via Valgrind, specifically Callgrind testing your commit and the commit prior to your commit. Both built in release. This is the command I'm using:

CARGO_TARGET_DIR="/tmp/m2" LD_LIBRARY_PATH="$(rustc --print=sysroot)/lib" valgrind --tool=callgrind --trace-children=yes ../../../release/cargo-clippy

In ripgrep for example I reported a 8% performance improvement both in icount and in wall time. Which is great!
My CPU is AMD Ryzen 7 5800X (16 threads) @ 4.85 GHz. Still, be it 10% or 20% performance improvement, it's great.

I'll give it a second review

[blyxyas]

LGTM, thanks! ❤️

View changes since this review

[flip1995]

changelog: none

Awesome work! Only comment I have is, that you should've added a changelog entry. This kind of perf improvement is definitely worth mentioning in our changelog. Maybe do that in the PR for early lint passes.

[xmakro]

changelog: none

Awesome work! Only comment I have is, that you should've added a changelog entry. This kind of perf improvement is definitely worth mentioning in our changelog. Maybe do that in the PR for early lint passes.

Thanks! The early lint pass was already merged. Is it possible for you to add an entry to the changelog manually? There are a few more PRs with smaller savings that could all be summarized under one changelog item.

[flip1995]

Thanks! The early lint pass was already merged. Is it possible for you to add an entry to the changelog manually? There are a few more PRs with smaller savings that could all be summarized under one changelog item.

Only if we remember ~10 weeks from now when the changelog is written. Pinging @alex-semenyuk who usually writes the changelog. This will need to be included in the 1.98.0 changelog.

I added the beta-accepted label, since those are checked during changelog writing anyway. But this is for 1.98, not 1.97.

[ada4a]

Could you please also update the docs at

rust-clippy/book/src/development/defining_lints.md

Lines 178 to 198 in 2ba3d1c

	## Lint registration
	If we run the `cargo dev new_lint` command for a new lint, the lint will be
	automatically registered and there is nothing more to do.
	However, sometimes we might want to declare a new lint by hand. In this case,
	we'd use `cargo dev update_lints` command afterwards.
	When a lint is manually declared, we might need to register the lint pass
	manually in the `register_lints` function in `clippy_lints/src/lib.rs`:
	```rust
	store.register_late_pass(|_| Box::new(foo_functions::FooFunctions));
	```
	As you might have guessed, where there's something late, there is something
	early: in Clippy there is a `register_early_pass` method as well. More on early
	vs. late passes in the [Lint Passes] chapter.
	Without a call to one of `register_early_pass` or `register_late_pass`, the lint
	pass in question will not be run.

to reflect this change? Thanks in advance:)