Generate StorageLive after DropAndReplace for locals

[tmandry]

Fixes a problem in #60840 where I forgot to consider DropAndReplace.

That PR assumes that a MIR Drop terminator implies StorageDead along both edges for locals. During drop elaboration, we turn DropAndReplace into a Drop followed by an assignment, which would incorrectly then be seen as an assignment to a local that's StorageDead. To compensate, we declare that the local is StorageLive again before assigning.

I did some local benchmarking on this change and didn't see any regressions. I wasn't running the full suite, however.

I have a test which reproduces the problem. It will be included in #60187, since I need that optimization in place for the problem to actually manifest.

[rust-highfive]

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

[cramertj]

@bors try (for perf)

@RalfJung WRT correctness of this change, is it guaranteed that a place that is treated as StorageDead followed by StorageLive won't be moved to another location in memory? That is, I'd expect assignment to result in a variable that has the same address as the previous place prior to the assignment.

Do we have any kind of documentation for these sorts of guarantees on MIR?

[bors]

⌛ Trying commit 201b464 with merge 8044de50b3d0a2ec814b74c2c61416e712b4ba9c...

[bors]

💥 Test timed out

[Centril]

Do we have any kind of documentation for these sorts of guarantees on MIR?

also cc @pnkfelix @nikomatsakis @arielb1

[Centril]

@bors rollup

[RalfJung]

is it guaranteed that a place that is treated as StorageDead followed by StorageLive won't be moved to another location in memory?

No. It will be at a different location in memory, in general (and in Miri). It is quite explicitly the goal of the Storage* annotations that when a variable is live again, it might be at a different location. This is the only reason why you can assume that, after a StorageDead, all pointers to the location are and always will be unusable.

Without this, your generator optimization would be unsound (as the location could be revived after the drop).

So, this change is incorrect and does not help to solve the issue, I am afraid.

[tmandry]

Closing in favor of #61373.