Impls and impl items inherit dead_code lint level of the corresponding traits and trait items

[mu001999]

https://github.com/rust-lang/rust/blob/master/compiler/rustc_passes/src/dead.rs#L360-L361 won't insert assoc items into the live set, so that impl items cannot be marked live.

This PR lets impls and impl items can inherit lint levels of the corresponding traits and trait items.

Fixes #144060

r? @petrochenkov

[compiler-errors]

This behavior seems really non-local and pretty broad. #[allow(dead_code)] on a trait definition suppresses all dead code warnings in all impls with this change?

[mu001999]

#[allow(dead_code)] on a trait definition suppresses all dead code warnings in all impls with this change?

@compiler-errors yes, and I think this makes sense. We would have only one trait definition but many impls, letting #[allow(dead_code)] on traits propagate to impls is convenient. Otherwise we need to add #[allow(dead_code)] also on each impls which use unused items.

[petrochenkov]

r? @compiler-errors

[petrochenkov]

Hmm, why did rustbot assign it to me again?
I'll just block this on #144863 now.
@rustbot blocked

[mu001999]

Hmm, why did rustbot assign it to me again?

I tried reassigning, but rustbot didn’t respond after waiting a while, so I deleted the comment. 😂

[bors]

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

[mu001999]

@rustbot ready

[tgross35]

@cjgillot gentle ping for a review here

[wesleywiser]

Nominated the issue for lang team discussion, let's see what they think before merging.

[mu001999]

oh, I missed the non-local in the note from @compiler-errors

and if the trait is non-local, the dead-code lint level won't spread to the local impls. cc @wesleywiser

we only care about local traits, see https://github.com/rust-lang/rust/pull/144113/files#diff-719b4f36bbbf3b3bf48683429408f5d27e5633f70c1144a93554bd536d5bf655R786

[jdonszelmann]

@bors r+ rollup

[bors]

📌 Commit 12474ce has been approved by jdonszelmann

It is now in the queue for this repository.

[JonathanBrouwer]

Candidate for the perf regression in #150726
@rust-timer build bb5b182

[rust-timer]

Finished benchmarking commit (bb5b182): comparison URL.

Overall result: ❌✅ regressions and improvements - 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.4%	[0.2%, 0.8%]	13
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.6%	[-0.6%, -0.5%]	3
All ❌✅ (primary)	0.4%	[0.2%, 0.8%]	13

Max RSS (memory usage)

Results (primary -0.6%)

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)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-0.6%, -0.6%]	1

Cycles

Results (secondary 4.1%)

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.1%	[3.2%, 5.0%]	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: 473.921s -> 475.634s (0.36%)
Artifact size: 390.82 MiB -> 390.83 MiB (0.00%)

[JonathanBrouwer]

Yeah seems like this PR is the cause sadly, what action should we take to resolve this?

[Mark-Simulacrum]

I'm going to mark as triaged. This only significantly affected bitmaps in the non-incremental scenarios, and the change looks fairly minimal to me -- not clear that it could be made any better -- so I don't think there's much to be done here given this is effectively a new feature.