Make transmuting inhabited to uninhabited types an error

[canndrew]

This changes the behaviour of the transmute intrinsic so that, for any
uninhabited type Void and any inhabited type NonVoid:

• transmute::<Void, T> is okay
• transmute::<NonVoid, Void> is an error

[nagisa]

transmute::<Void, T> is okay

This can’t be possibly called, can it? Good thing you cannot get function pointer of an intrinsic, as making one up for this particular function would be kinda tricky :)

Overall this patch LGTM.

[oli-obk]

the issue code should probably be used as a regression test.

[durka]

@nagisa you can still construct a void by using transmute_copy or pointer casts (both seem to correctly invoke UB), so it could still be called.

[arielb1]

I think we should rather be changing the code in trans::block to make transmuting to a ! result in an unreachable, rather than hackily adding errors. At the ty::layout level, I would imagine we want to propagate this further.

Why are you making transmute::<Void, NonVoid> legal? That is an odd exception to the same-size rule.

[canndrew]

At the ty::layout level, I would imagine we want to propagate this further.

The hackyness begins at whatever level we start pretending that uninhabited types are ZSTs, so I agree that the lower we can push that the better. What exactly do you have in mind though?

Why are you making transmute::<Void, NonVoid> legal?

Why not? It's always safe to transmute from an uninhabited type to anything else (every element of Void has the same size as T for any T). Plus, transmute::<A, B> isn't a symmetrical operation w.r.t. the types A and B so it's not necessarily more elegant to make it symmetrical w.r.t. their sizes inhabitedness. I wouldn't feel strongly about changing it though.

[alexcrichton]

ping, what's the status of this?

[canndrew]

@alexcrichton It prolly needs the lang team to have a look at it and see if they agree with it. Other than that though it should be good to merge.

[steveklabnik]

/cc @rust-lang/lang

Also, there's no reviewer for this? I'm not sure who should be assigned.

[aturon]

r? @eddyb

[eddyb]

The patch is alright, I suppose, but I don't understand the motivation between this change.
AFAICT the main effect is making transmute::<ZST, Void> an error (which requires at least a crater run).

[canndrew]

AFAICT the main effect is making transmute::<ZST, Void> an error

Correct. Because it's an insane thing to do and it has the same problems as uninitialized::<Void>. That said, I'm starting to feel we should settle the questions around uninitialized::<Void> first before merging anything like this :/

[eddyb]

I definitely want a bunch of warnings in this area, not so sure about outright errors.
Deny-by-default lints are quite good at this sort of bad-unsafe-code sort of thing IMO.

[alexcrichton]

If we're thinking of holding off on this until we've settled more questions about uninitialized types, perhaps we should close in the meantime? (to help clear out the queue)

[canndrew]

@alexcrichton Righto. Closed for now.