Change AdtDef's PartialEq and Hash impls to use DefId

[Aaron1011]

No description provided.

[rust-highfive]

r? @matthewjasper

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 4233b73 with merge 459ffcf2c335b383b9459fd457201770509d8c73...

[bors]

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

[rust-timer]

Queued 459ffcf2c335b383b9459fd457201770509d8c73 with parent 2595d03, future comparison URL.

[Mark-Simulacrum]

Note that due to merging rust-lang/rustc-perf#1123, these runs may look quite bad -- once we get another master commit landed + benchmarked, re-running perf should make any noise there go away. It shouldn't affect non-incremental results, though, of course.

(Leaving this comment on all pending perf run PRs).

[rust-timer]

Finished benchmarking commit (459ffcf2c335b383b9459fd457201770509d8c73): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

• Moderate improvement in instruction counts (up to -0.7% on incr-full builds of externs)
• Very large regression in instruction counts (up to 133.3% on incr-unchanged builds of ctfe-stress-4)

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 led 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

[Aaron1011]

Re-running to get accurate incremental perf results:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 4233b73 with merge df6895368ef88ce97b479cd8c8bbaaa94cad07df...

[bors]

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

[rust-timer]

Queued df6895368ef88ce97b479cd8c8bbaaa94cad07df with parent d3f3004, future comparison URL.

[rust-timer]

Finished benchmarking commit (df6895368ef88ce97b479cd8c8bbaaa94cad07df): comparison url.

Summary: This change led to moderate relevant regressions 😿 in compiler performance.

• Moderate regression in instruction counts (up to 2.4% on incr-patched: println builds of regression-31157)

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 led 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

[Aaron1011]

Merged as part of #91924