Unstable `mir::interpret::AllocId`s in tests with parallel frontend

[zetanumbers]

Relates to #154314

We use AllocMap::next_id atomic counter to reserve AllocIds, which is globally shared via the GlobalCtxt::alloc_map. So when parallel frontend concurrently executes the interpreter it makes these ids unstable across different compilation sessions. As such tests exposing the AllocIds in diagnostics fail under the parallel frontend.

UI test failures under the parallel frontend

• const-generics/issues/issue-100313.rs
• const-generics/min_const_generics/invalid-patterns.rs
• const-ptr/forbidden_slices.rs
• const-ptr/out_of_bounds_read.rs
• consts/const-compare-bytes-ub.rs
• consts/const-err-enum-discriminant.rs
• consts/const-eval/c-variadic-fail.rs
• consts/const-eval/const-pointer-values-in-various-types.rs
• consts/const-eval/heap/alloc_intrinsic_uninit.rs
• consts/const-eval/heap/dealloc_intrinsic_dangling.rs
• consts/const-eval/heap/dealloc_intrinsic_duplicate.rs
• consts/const-eval/heap/dealloc_intrinsic_incorrect_layout.rs
• consts/const-eval/heap/make-global-dangling.rs
• consts/const-eval/heap/make-global-other.rs
• consts/const-eval/heap/make-global-twice.rs
• consts/const-eval/heap/ptr_made_global_mutated.rs
• consts/const-eval/issue-49296.rs
• consts/const-eval/ptr_fragments_mixed.rs
• consts/const-eval/raw-bytes.rs
• consts/const-eval/raw-pointer-ub.rs
• consts/const-eval/read_partial_ptr.rs
• consts/const-eval/ub-enum-overwrite.rs
• consts/const-eval/ub-enum.rs
• consts/const-eval/ub-incorrect-vtable.rs
• consts/const-eval/ub-nonnull.rs
• consts/const-eval/ub-ref-ptr.rs
• consts/const-eval/ub-upvars.rs
• consts/const-eval/ub-wide-ptr.rs
• consts/const-eval/union-const-eval-field.rs
• consts/const-eval/union-ice.rs
• consts/const-eval/union-ub.rs
• consts/copy-intrinsic.rs
• consts/interior-mut-const-via-union.rs
• consts/issue-63952.rs
• consts/issue-79690.rs
• consts/miri_unleashed/static-no-inner-mut.rs
• consts/missing_span_in_backtrace.rs
• consts/offset_ub.rs
• intrinsics/intrinsic-raw_eq-const-bad.rs
• type/pattern_types/validity.rs

Possible fix for related test failures: #156716

[bjorn3]

I don't think AllocId is supposed to be stable in the first place. It is similar to DefId in that it is just an incrementing id to some other value. Also how would we make it stable at all without serializing const eval?

[zetanumbers]

I don't think AllocId is supposed to be stable in the first place. It is similar to DefId in that it is just an incrementing id to some other value.

Yes, I understand that. I should have named this issue more clearly to begin with as it's only a testsuite problem.

Also how would we make it stable at all without serializing const eval?

We could do that by using TreeNodeIndex tracking parallel tasks from #149849, but I don't recommend spending your time on it as ain't no way it's gonna merged ever.

[petrochenkov]

Alloc IDs are now normalized in the test suite - #156716.