Reland "Merge CrateDisambiguator into StableCrateId"

[bjorn3]

Reverts #85891 as this revert of #85804 made perf even worse.

r? @Mark-Simulacrum

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 7b9344569e580ced3c0b4ded3675666e54da53a2 with merge 35615666ae78a7f7a1285b121d646fa27b66a48b...

[petrochenkov]

Reverts #85891 as this revert of #85804 made perf even worse.

inb4 this PR makes performance worse once again

[bjorn3]

@rust-timer build 35615666ae78a7f7a1285b121d646fa27b66a48b

[rust-timer]

Queued 35615666ae78a7f7a1285b121d646fa27b66a48b with parent a50d721, future comparison URL.

[rust-timer]

Finished benchmarking try commit (35615666ae78a7f7a1285b121d646fa27b66a48b): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[bjorn3]

Perf is positive.

[michaelwoerister]

Are we sure that the crate-disambiguator concept isn't user facing?

[bjorn3]

StableCrateId takes the place of crate disambiguator. The fact that different crates with the same name, but different -Cmetadata can be linked together, but with the same -Cmetadata can't is user-facing. StableCrateId contains both the crate name and -Cmetadata meaning that this linking behavior is still the case. I don't think there is any other user-facing way for crate disambiguators. The new symbol mangling scheme uses the crate disambiguator and now stable crate id, but we don't guarantee anything about this hash anyway, not even that it is a hash I think. I think a random number would also be a valid implementation.

[michaelwoerister]

OK, I'm convinced. The StableCrateId can still be viewed as a crate disambiguator.

[bors]

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

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 0daecc5012cb1f19d79c782484d67fbdd71af78b with merge 5082b9fb6e9772786e675fcabf28d3971db2e657...

[bors]

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

[rust-timer]

Queued 5082b9fb6e9772786e675fcabf28d3971db2e657 with parent b17d9c1, future comparison URL.

[rust-timer]

Finished benchmarking try commit (5082b9fb6e9772786e675fcabf28d3971db2e657): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[bjorn3]

Dropped 158d3b9 as the size of DepNode doesn't change anymore.

[bjorn3]

@bors r=michaelwoerister

[bors]

📌 Commit 56c6a48 has been approved by michaelwoerister

[bors]

⌛ Testing commit 56c6a48 with merge d04ec47...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing d04ec47 to master...

[rust-highfive]

📣 Toolstate changed by #86143!

Tested on commit d04ec47.
Direct link to PR: #86143

💔 rls on windows: test-pass → build-fail (cc @Xanewok).
💔 rls on linux: test-pass → build-fail (cc @Xanewok).