Make parallel frontend alloc-id numbering deterministic and re-enable the tests

[xmakro]

Part of #154314. Addresses the "different alloc ids" row (#154278).

A group of const-eval ui tests were marked //@ ignore-parallel-frontend different alloc ids. AllocIds are handed out from a global counter, so under -Zthreads the numbers in the output differ run to run. compiletest already normalizes this: it remaps allocN to ALLOC{index} by order of first appearance (runtest.rs), so a pure renumbering does not affect the comparison.

For most of these tests the renumbering is the only difference. Each one emits a single const-eval error, or emits its errors in a deterministic order because const items are evaluated during the analysis phase rather than during parallel mono collection, so the order of first appearance is stable and the normalized output matches the single-threaded blessing. The first commit removes the directive from those tests and blesses the line numbers that shift from removing the directive line. No test output content changes, only span line numbers.

The remaining tests emit several const-eval errors whose emission order is itself nondeterministic under the parallel front-end. That reshuffles which allocation appears first, so the order-of-first-appearance normalization assigns different ALLOC indices and the normalized line text differs run to run.

To fix that at the source, the second commit makes compiletest sort the rendered diagnostics by their primary source location before it renumbers allocation ids. The first-appearance order then no longer depends on the racy emission order, so the ALLOC numbering is stable. Ties at the same location are broken by the diagnostic text with the raw allocation numbers blinded, since those numbers are racy too. The sort only runs under the parallel front-end, where stderr is already compared line by line, so single-threaded output is unchanged. With that in place the third commit re-enables the remaining ten tests.

Validation: every re-enabled test passes single threaded and under --parallel-frontend-threads=16 --iteration-count=100 --force-rerun (the multi-allocation ones at 200). Removing the directive shifts span line numbers by one and nothing else; the .32bit.stderr files, which cannot be blessed on a 64-bit host, were updated with the same shift and verified against the .64bit.stderr delta. A baseline run with the sort disabled confirms all ten fail without it and that no other test changes behavior under the parallel front-end.

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tiif (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 18 candidates

[zetanumbers]

Hi there. Could you replace these directives with an empty line instead to reduce gitdiff?

View changes since the review

[petrochenkov]

Then alloc ID normalization needs to happen somewhere in fn normalize_output, not in fn extract_rendered.

This task was already taken by #156716, that PR just needs to move the normalization to compiletest, so I'll close this PR.