Avoid nondeterminism in trimmed_def_paths

[Mark-Simulacrum]

Previously this query depended on the global interning order of Symbols, which
meant that irrelevant changes could influence the query and cause
recompilations. This commit ensures that the return set is stable and will not
be affected by the global order by deterministically (in lexicographic order)
choosing a name to use if there are multiple names for a single DefId.

This should fix the cause of the regressions in #83343.

[rust-highfive]

r? @petrochenkov

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

[Mark-Simulacrum]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 56fcf07 with merge bde948fea1e2e10b64d5edf9ca9c1aba01f2da10...

[Mark-Simulacrum]

(Nondeterminism is maybe not the right name -- a specific compilation should always be the same. But "irrelevant" changes can cause the behavior of this query to differ, which seems not great).

[bors]

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

[rust-timer]

Queued bde948fea1e2e10b64d5edf9ca9c1aba01f2da10 with parent 6dc08b9, future comparison URL.

[tgnottingham]

Seems like a good idea.

Outside the scope of this, but it might be nice if trimmed paths in error messages used the most appropriate name when there are multiple possibilities, taking into account any use ... as ... as applicable. That may get tricky if the error message involves multiple locations and they use different names for the same def id though.

[rust-timer]

Finished benchmarking commit (bde948fea1e2e10b64d5edf9ca9c1aba01f2da10): comparison url.

Summary: This benchmark run did not return any relevant changes.

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.

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

[rylev]

This indeed seems to fix the performance regressions we saw previously! 🎉

[petrochenkov]

@bors r+

[bors]

📌 Commit 56fcf07 has been approved by petrochenkov

[bors]

⌛ Testing commit 56fcf07 with merge edebf77...

[bors]

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

[rust-timer]

Finished benchmarking commit (edebf77): comparison url.

Summary: This benchmark run did not return any relevant changes.

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

@rustbot label: -perf-regression