Track derive attrs for more accurate suggestion

[estebank]

No description provided.

[rust-highfive]

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[estebank]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 867d666 with merge a04efadf063b0b15950cb94e70984666c444fa0a...

[bors]

☀️ Try build successful - checks-actions
Build commit: a04efadf063b0b15950cb94e70984666c444fa0a (a04efadf063b0b15950cb94e70984666c444fa0a)

[rust-timer]

Queued a04efadf063b0b15950cb94e70984666c444fa0a with parent 7b46aa5, future comparison URL.

[rust-timer]

Finished benchmarking commit (a04efadf063b0b15950cb94e70984666c444fa0a): comparison url.

Instruction count

• Primary benchmarks: mixed results
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	0.4%	0.4%	5
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-0.4%	-0.4%	1
Improvements 🎉 (secondary)	-1.2%	-2.2%	13
All 😿🎉 (primary)	0.2%	0.4%	6

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	2.8%	2.8%	1
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-8.2%	-8.2%	1
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-2.9%	-4.0%	3
All 😿🎉 (primary)	N/A	N/A	0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

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

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[estebank]

@petrochenkov I was looking at alternatives to address #98822. Because we remove the derive attr post-expansion, that information is understandably no longer available by the time we're doing trait evaluation as it never carries into the HIR. This is a hack to avoid potential unintended fallout, but would like to hear your take on how we could tackle this.

[Mark-Simulacrum]

FWIW, I think it may not be a bug worth fixing -- adding the extra context may almost be more confusing in my eyes than showing the derive standalone (e.g., leading to a conclusion that the extra bits are needed). It seems like more of a stylistic lint to keep all derives in the same block, maybe best for Clippy or rustfmt to do that re-arranging.

It probably adds to the confusion though that we're emitting a "code block" in the lint help text, rather than just saying to annotate with derive(Debug) without additional context. If that included the struct Foo then that would make more sense, but as-is seems like just noise to me.

[estebank]

If this approach isn't worth it, I'm closing this PR. We can look for alternative approaches (but I'm uncertain we'll find a better approach).