We currently actually assign two AllocId to every static/const: one pointing to the DefId (a "lazy" ID that can be created without evaluating anything), and one pointing to an actual Allocation (a "resolved ID" available only after it has been evaluated). Also see the comments added in #61278. The "resolved ID" should never be visible to other CTFE or Miri evaluations, because then we'd have two different IDs for the same allocation!

The second ID gets assigned when we intern the result of const evaluation. Or rather, it gets assigned and added to the local map of the CTFE engine when we allocate the return place for const evaluation, which is later used as the root for interning at which point it gets moved into the global tcx allocation map.

First of all, are we entirely sure that the stuff we intern will not use the resolved ID anywhere? Rust provides no "obvious" way to take the address of the return place, and I think that would be the only way the "resolved ID" could leak into the evaluated program. Still, can we make interning not intern the "root", just to be really sure that if that ID leaks somehow it will not cause problems? Or even better, can we not allocate a new ID for the return place and instead use the "original" ID? In the CTFE engine, that ID could map to an Allocation in the local memory map, even though it maps to a Static in the global tcx memory. By avoiding even assigning a second ID we'd avoid all problems!

If we cannot avoid assigning a second ID, we also have to make sure that other computations, when they request the content of a static, do not use the "resolved ID". Currently, the const_eval_raw query will return a RawConst pointing exactly to that "resolved ID". Maybe we should instead make it return a &'tcx Allocation? We don't really need the ID in there because whoever made the const_eval_raw query obviously had the DefId needed to do that and that's all it takes to lookup the "lazy" ID in the tcx! But we could still include it for convenience.

Cc @oli-obk