Improve incremental use of lint filtering

[blyxyas]

Via making the query DefId dependant instead of running on the whole crate, we can reuse the shallow lint map of previously-visited items in other runs.

Similar to the approach that would maybe help with #144927

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[blyxyas]

@bors2 try @rust-timer queue

[rust-bors]

⌛ Trying commit c5599e0 with merge 30964bb…

To cancel the try build, run the command @bors try cancel.

[cjgillot]

A few ideas:

• make the return type a dedicated struct;
• replace dont_need_to_run.contains(lint) by a call to inherent method should_run(lint);
• perform the check for future breakage and lint_cap in that method;
• compute this query per module, and only recurse inside that module.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 30964bb (30964bb6a3917906f7a66d9ec19599520090222c, parent: 18eeac04fc5c2a4c4a8020dbdf1c652077ad0e4e)

[rust-timer]

Finished benchmarking commit (30964bb): 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.3%	[0.2%, 0.7%]	72
Regressions ❌ (secondary)	0.9%	[0.1%, 3.0%]	60
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	3
All ❌✅ (primary)	0.3%	[0.2%, 0.7%]	72

Max RSS (memory usage)

Results (primary 1.9%, secondary 3.5%)

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

	mean	range	count
Regressions ❌ (primary)	3.4%	[1.5%, 7.8%]	6
Regressions ❌ (secondary)	5.7%	[2.2%, 12.7%]	9
Improvements ✅ (primary)	-7.2%	[-7.2%, -7.2%]	1
Improvements ✅ (secondary)	-1.5%	[-2.2%, -1.3%]	4
All ❌✅ (primary)	1.9%	[-7.2%, 7.8%]	7

Cycles

Results (secondary -0.7%)

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)	5.3%	[2.2%, 8.4%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-6.8%	[-7.6%, -5.9%]	2
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 462.481s -> 464.365s (0.41%)
Artifact size: 377.60 MiB -> 377.23 MiB (-0.10%)