What are the operational semantics of unsized locals?

[RalfJung]

Unsized locals as they exist in MIR today have an entirely unclear operational semantics. If we intend to keep them, we should figure out a way to represent them in MIR properly; the current situation is not long-term sustainable.

[Diggsey]

What do you expect a solution to look like? Some way to specify the runtime metadata before StorageLive, like:

StorageMeta(x, Meta(y))
StorageLive(x);
x = Move(y);

?
Or is there a more fundamental problem with not necessarily knowing y at the point where the storage needs to be live?

[RalfJung]

I don't know what StorageMeta on its own would do in your proposal. So I was thinking more like:

StorageLive(x, Meta(y));
x = Move(y);

However, that still requires the concept of an "unsized value" (the thing that is loaded from Move(y) and then stored into x), and I am not sure yet whether that is a meaningful concept. (It may well be, but it needs to be given some thought.) And if is entirely unclear to me how this would ever be extended to user-defined unsized types, but maybe it's better to first design something that works for our existing unsized types.

Though honestly an even better option might be to entirely desugar this to explicit pointers at the level of MIR, like:

let x: *mut UnsizedType;

x = AllocaUnsizedType(Meta(y));
CopyNonoverlapping(x, y);

[Diggsey]

Though honestly an even better option might be to entirely desugar this to explicit pointers at the level of MIR, like:

Wouldn't that make borrow-check difficult?

[RalfJung]

Maybe this should be done as a lowering pass after borrowck. Though then the MIR borrowck runs on wouldn't really have an op.sem...