Output deterministic AllocIds when emitting MIR

[aerooneqq]

Fixes #154278. Blocked by #161450.

r? @petrochenkov

[bjorn3]

How would you show the original alloc ids if you need them for debugging? Also this would lose the ability to tell alloc ids between different mir bodies apart, right?

View changes since the review

[aerooneqq]

How would you show the original alloc ids if you need them for debugging?

Maybe with special --emit mode (like --emit=mir-original).

Also this would lose the ability to tell alloc ids between different mir bodies apart, right?

Yes, and I am now working on it by trying to overwrite tcx.alloc_map.to_alloc for consistent remapping across different bodies and for correct access to allocations through tcx.try_get_global_alloc (unfortunately AllocId can randomly appear in Debug implementations and maybe somewhere else; if it tries to access allocation through remapped allocation id this will lead to an error), however at this stage I don't like the resulting solution from many points of view, so I am not sure that this problem can be solved with this approach.

[aerooneqq]

After some experiments from technical side I don't see adequate solution for now, as during MIR dump we use MIR models directly without prior creation of DTO models specifically for printing/dumping, thus we need to adjust regular data structures in the compiler to remap allocation ids, more specifically tcx.alloc_map.to_alloc. We can add API to edit this map inplace, however it is not clear what is the lifetime of this remap and how long we should keep remapped allocation ids in this map. Adding second map which will track remappings and add two-map search for allocation may cause perf regression and it leaves the same question: how long should we keep remapping alive. One approach is to remove it on drop of MirWriter but this will cause remapping to be re-applied for every instance of MirWriter, and I am not even considering possible cases of parallel dumping/writing of MIR.

From logical point of view it seems like we do not need such a remapping, because non-deterministic MIR output is not that critical compared to deterministic binaries or metadata, next for debug purposes it is better to view original MIR that can be obtained from non-parallel compiler. Finally, in tests we have normalization which removes allocation ids, so remapping is not needed.

Other option is to make creation of allocation ids deterministic in its core, now it is just a number which gets atomically incremented from different threads, so for determinism we need to alter its structure, which likely to cause perf regressions and seems like not worth doing for the purpose of fixing #154278 (at least for now).

[petrochenkov]

Finally, in tests we have normalization which removes allocation ids, so remapping is not needed.

This can potentially be done in the rustc instead of compiletest.
With -Zui-testing various numbers like diagnostic line numbers are already normalized to LL, we could do the same thing with allocation IDs in diagnostics and dumps, so they are "anonimized" if UI testing is enabled.
-Zui-testing=false would then act as the --emit=mir-original suggestion from #161768 (comment), except that it is the default behavior.