Clarify when StorageLive is legal

[RalfJung]

StorageLive compiles to llvm.lifetime.start. It is an open question whether it is allowed to call StorageLive on a local that has already been marked as live. Currently, rustc emits code that relies on this being okay.
To account for some optimizations that LLVM has been caught performing, at the very least, we have to declare that StorageLive resets the contents of a local back to Undef. It seems this is consistent with what rustc currently emits.

See rust-lang/rust#42371 for more details.

[strega-nil]

Is this an official part of Rust? It seems weird to define a memory model for a non-rust language.

[RalfJung]

StorageLive/StorageDead are in MIR; so I'd say they are as official as it gets. If we want their translation to LLVM to be sound, we better make them have a semantics that rules out everything LLVM forbids (and maybe more).

[strega-nil]

@RalfJung I've never thought of MIR as an "official" part of Rust - just an implementation detail. See mrustc, which doesn't use the same MIR.

[RalfJung]

Fair enough.

The road I am pursuing (and there's hopefully going to be a blog post with more details) is to develop a spec for MIR, and then specify Rust by translation to MIR. I feel that makes sense because MIR is a very nice "core" language without all the redundancy of surface Rust.

That doesn't mean all compilers have to use MIR; it just means that the behavior of Rust code is defined by means of what the corresponding MIR code does.

EDIT: I realized I actually laid out this strategy in https://www.ralfj.de/blog/2017/05/23/internship-starting.html, so I just extended that post a little to cover your objection about not all compilers using MIR.

[RalfJung]

This issue moved to rust-lang/unsafe-code-guidelines#129.