Revert "Merge CrateDisambiguator into StableCrateId"

[bjorn3]

This reverts #85804

[rust-highfive]

r? @varkor

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

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 233cb5257afb4a8f3fa9e9e811acd7df9618560b with merge 6b2fbdd1b6592ef0db81db389dc81360ed9cc848...

[bors]

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

[rust-timer]

Queued 6b2fbdd1b6592ef0db81db389dc81360ed9cc848 with parent 1160cf8, future comparison URL.

[rust-timer]

Finished benchmarking try commit (6b2fbdd1b6592ef0db81db389dc81360ed9cc848): 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

[varkor]

Seems like a perf improvement. Going to leave to r? @Mark-Simulacrum for the decision.

[Mark-Simulacrum]

r=me, unfortunately looks like this has a bunch of merge conflicts now

[bjorn3]

Rebased

[bjorn3]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 8176ab8 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 8176ab8 with merge 2312ff1...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 2312ff1 to master...

[Mark-Simulacrum]

It doesn't seem like reverting this actually recovered performance -- this PR is a regression just like the merge run on the original was.

@bjorn3 my guess is that maybe reverting the revert is a good idea but I noted you suggested some possible performance improvements on the original diff (#85804 (review)) which might be worth considering. Ultimately seems like other PRs landing in between are likely causing problems with measuring and comparing this PR.

[bjorn3]

Revert in #86143. I will wait with perf improvements until #85834 is merged as it introduces a method that is needed for some of the possible perf improvements.