Stabilize transmute in constants and statics but not const fn

[oli-obk]

r? @Centril

We already have unions inside constants and it's strictly better to use transmute for transmutation purposes since you also get a size check.

[est31]

Why not also stabilize them in const fn?

[oli-obk]

If we permit transmute in const fn, we need to talk about "const soundness" first. Right now there is no way one can write a const fn whose behaviour differs between runtime and compile-time. Once you can do really unsafe things in const fn, we need to make sure everyone is aware that if you make a const unsound const fn, then you can cause UB, even if the thing isn't UB at runtime.

[bors]

☔ The latest upstream changes (presumably #64026) made this pull request unmergeable. Please resolve the merge conflicts.

[Centril]

Hmm... I'm skeptical about diverging const items and const fn more than we have to. The size check may be nice but I'm personally not a big fan of it since it's a type system complication right now and if you actually cause UB with a union then CTFE will throw a fit and error...

[RalfJung]

if you actually cause UB with a union then CTFE will throw a fit and error...

It might not be UB though, just reading the wrong data, if e.g. a union U { f1: u32, f2: u16 } starts to right-align the fields.

Given that const already have this capability, I think it only makes sense to also expose it ergonomically. However, union only works on Copy types; we should make sure transmute working on all types does not cause new problems.

I'm skeptical about diverging const items and const fn more than we have to.

That's fair. OTOH, I feel like const items provide a nice testing ground for us to stabilize CTFE features in a very controlled way -- since we do a validity check on the result, nothing "way too weird" should be able to happen.

[RalfJung]

I also think stabilization should be blocked on #61495 being resolved. We should make sure our intrinsic const checks actually check what we want them to check, before stabilizing direct access to an intrinsic in CTFE.

[JohnCSimon]

Ping from triage
@oli-obk Can you please fix the merge conflicts?
Thanks.

[oli-obk]

I'll close this until #61495 is resolved.

[jplatte]

@oli-obk #61495 is resolved now. Will you re-open this PR / create a new one?

[oli-obk]

Uh, I just realized this scheme isn't possible anymore. We either stabilize const_transmute everywhere or nowhere.

[RalfJung]

@oli-obk could you explain why?

[RalfJung]

@oli-obk should we give this another try? Not much progress has been made on the unconst side of things, but allowing transmute where we already allow union could help get rid of a lot of nasty union-type-punning code (probably half of which is wrong because it forgets to add repr(C) to the union).

[oli-obk]

Before we do that we should probably get rid of the extra min_const_fn logic, and instead integrating its checks into the new const checking infrastructure.

Oh well, we could just do it in min_const_fn :/ yea no need to block it. I'll rebase this and fix it up

[oli-obk]

Ah, trying that I now remember what the problem is:

we declare intrinsics to be stable by adding the rustc_const_stable attribute to them... There's no concept for undoing that just for const fn. I can add a specific check just for const fn, but if we plan on doing more of these, we'll need a new attribute.

[oli-obk]

let's continue any further discussion in #53605