Hash Ident spans in all HIR structures

[Aaron1011]

This PR removes all of the #[stable_hasher(project(name))]
attributes used in HIR structs. While these attributes are not known
to be causing any issues in practice, we need to hash these in
order for the incremental system to work correctly -
a query could be otherwise be incorrectly marked green
when a change occures in one of the Spans that it uses.

[rust-highfive]

r? @Mark-Simulacrum

(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 467b726 with merge e70d7c42c557e3314300eb6a0bf4a99bdbdfa358...

[bors]

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

[rust-timer]

Queued e70d7c42c557e3314300eb6a0bf4a99bdbdfa358 with parent ddabe07, future comparison URL.

[rust-timer]

Finished benchmarking commit (e70d7c42c557e3314300eb6a0bf4a99bdbdfa358): comparison url.

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

• Large regression in instruction counts (up to 1.7% on incr-unchanged builds of serde)

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

[petrochenkov]

This is a subset of #92210, but without parts that are really problematic for performance.
r? @petrochenkov@bors r+

[bors]

📌 Commit 467b726 has been approved by petrochenkov

[bors]

⌛ Testing commit 467b726 with merge 7a0a0a233a0b289f1b1c29d30abed4fa94642de5...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

A job failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

[petrochenkov]

@bors retry

[bors]

⌛ Testing commit 467b726 with merge 6299c843455584a472fb8abe92b600eafc7f732e...

[bors]

💥 Test timed out

[Aaron1011]

@bors retry

[rust-log-analyzer]

A job failed! Check out the build log: (web)(plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

⌛ Testing commit 467b726 with merge 092e1c9...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 092e1c9 to master...

[rust-timer]

Finished benchmarking commit (092e1c9): comparison url.

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

• Large regression in instruction counts (up to 1.6% on incr-unchanged builds of derive)

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

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

[rylev]

@Aaron1011@petrochenkov am I correct in assuming that we're on with the perf regressions since this is a correctness fix? Is there any path potentially for gaining some of the perf back? I see that this is a subset of #92210 which has absolutely horrific performance regressions. Would it make sense to try to gain back as much of the perf lost with this PR first before landing the subsequent one?

[petrochenkov]

@rylev
Looks like the rest of #92210 was superseded by #92533, so it likely can be closed now.