Detect unused struct impls pub trait

[mu001999]

Fixes #47851

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
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

[mu001999]

r? @shepmaster

[shepmaster]

I'll give this a look-through, but I'm definitely not qualified to give it a final sign-off 🙂.

r? rust-lang/compiler

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[mu001999]

New pending PR:

• remove unused struct Snap in lsif rust-analyzer#16795
• Subtree update of rust-analyzer #122272: Subtree update of rust-analyzer contains the above PR

[bors]

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

[mu001999]

@pnkfelix @shepmaster No pending PRs, could you reapprove? Thanks ;)

[shepmaster]

@bors r=pnkfelix

[bors]

📌 Commit c73a7f0 has been approved by pnkfelix

It is now in the queue for this repository.

[bors]

⌛ Testing commit c73a7f0 with merge c69fda7...

[bors]

☀️ Test successful - checks-actions
Approved by: pnkfelix
Pushing c69fda7 to master...

[rust-timer]

Finished benchmarking commit (c69fda7): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.2%, 0.5%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.2%, 0.5%]	6

Max RSS (memory usage)

Results

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)	1.9%	[1.9%, 1.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.0%	[-2.4%, -1.1%]	10
Improvements ✅ (secondary)	-2.8%	[-4.0%, -2.3%]	13
All ❌✅ (primary)	-1.6%	[-2.4%, 1.9%]	11

Cycles

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

Binary size

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

Bootstrap: 648.469s -> 647.708s (-0.12%)
Artifact size: 309.94 MiB -> 309.95 MiB (0.00%)

[pnkfelix]

Visiting for weekly rustc-perf triage.

@mu001999 it looks like the performance regression flagged here is legitimate, even though it is also minor. I.e., the performance stats indicate that the newly added worklist code is the source of a bit of extra time we are spending here.

Do you have any ideas on ways we might attempt to avoid the extra cost?

If not, that is okay; we just need to keep our eyes on how these things add up, and make sure we don't end up slowing down the compiler too much for lints that may not be paying for themselves.

[mu001999]

Do you have any ideas on ways we might attempt to avoid the extra cost?

@pnkfelix maybe we can make unsolved impl items as a map from adt def id to impl item ids, and update next-to-solve impl terms if finding a used adt when visiting trait items. Then we don't need traversal all unsolved impl items every time until there are no unsolved items. But I don't know if this will reduce the extra time.

[pnkfelix]

Yeah that sounds like a potential idea. Its not something you need to take on yourself, I just want to try to get the ideas written down while the code is still fresh in our heads.