Currently, we disallow StorageLive being called on a local that is already live (both in Miri, and in the MIR docs). This was originally motivated by some very vague wording in LLVM making it unclear whether LLVM would behave properly when there are multiple lifetime.start without intermediate lifetime.end.

However, LLVM has in the mean time clarified that such a redundant lifetime.start is fine, and just resets the contents of the storage to be uninitialized. So @JakobDegen is suggesting that we change our StorageLive semantics for the case where the local is already live: this could be be defined behavior, and it will re-allocate the backing local, potentially giving it a new address and resetting its contents to be uninitialized.

I do not have any fundamental objections to this, but I also don't know if this could cause other problems, or maybe even help in other situations. Having such a "reallocation" primitive has previously been suggested by @tmandry ; the proposed semantics would mean we don't need another primitive. But maybe some MIR opts would prefer the stricter interpretation of the storage annotations? #98896 sounds like @vakaras would prefer a stricter interpretation than what we currently implement for StorageDead, so making StorageLive more relaxed might be a problem for them.

So, let's collect all the potential benefits of the current semantics of StorageLive before deciding that we change it. (And also all benefits of the change, of course.)

Cc @rust-lang/wg-unsafe-code-guidelines @rust-lang/wg-mir-opt