Miri provenance cleanup

[RalfJung]

Reviewing #95826 by @carbotaniuman made me realize that we could clean things up a little here.

@carbotaniuman please let me know if you're okay with landing this (it will create a lot of conflicts with your PR), or if you'd prefer incorporating the ideas from this PR into yours. I think we want to end up in a situation where the function you called ptr_reify_alloc returns just two things, a concrete tag and an offset. Getting an AllocId from a concrete tag should be infallible like now. However a concrete tag and Tag don't have to be the same type.

r? @oli-obk

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[RalfJung]

Getting an AllocId from a concrete tag should be infallible like now. However a concrete tag and Tag don't have to be the same type.

Or maybe it returns 3 things: AllocId, offset, and TagExtra. But either way there should be no redundancy in what it returns.

I feel like this triple approach might be better for #95826 since it avoids having to extract the AllocId from a ConcreteTag. If you want to do that @carbotaniuman let me know, otherwise I can do it in this PR -- the first commit remains the same, but the second commit would instead change the type of the third component to a new associated type that needs to be added to the machine. The hardest part about this is naming that new associated type... TagExtra isn't that great.

[carbotaniuman]

I like these changes, but I can't tell how the difference between the two and three element approaches will affect my code.

However a concrete tag and Tag don't have to be the same type.

Can you clarify this? It looks like according to these changes that all Pointer<M::PointerTag> can infallibly get an AllocId, which isn't the semantics that are needed.

[RalfJung]

Can you clarify this? It looks like according to these changes that all Pointer<M::PointerTag> can infallibly get an AllocId, which isn't the semantics that are needed.

I have added it to this PR.
On top of this PR I think you can leave the signature of ptr_get_alloc_id (and the other similar methods) unchanged. You can make Provenance::get_alloc_id and Machine::ptr_get_alloc fallible and add the hooks for ptr2int and int2ptr casts and that should be all the changes that are needed. It should be fairly local.

[RalfJung]

Technically, this is currently still redundant -- we could make this ptr_get_offset and have it return just a Size, and get all the other data directly from the PointerTag.

But in preparation for @carbotaniuman's PR, I think we should leave this the way it is. After that PR, Provenance::get_alloc_id should be called only for diagnostics and when Provenance::OFFSET_IS_ADDR == false, and ptr_get_alloc should be used throughout the machine to extract information from provenance. (And that's what we already do, so it would be silly to change it back and forth.)

[oli-obk]

@bors r+

[bors]

📌 Commit 55f0977 has been approved by oli-obk