Allow limited transmuting between types involving type parameters

[illicitonion]

Before this change, functions could never perform transmutes between types which involve type parameters.

This opens up slightly less limited analysis whereby certain types involving Sized type parameters can be considered relative to each other, even if the exact size of that type parameter isn't yet known because monomorphization hasn't happened yet. Specifically it allows:

1. repr(transparent) types to be considered to have the same size as the Sized type they wrap.
2. Arrays of type parameters (or repr(transaprent) wrappers thereof) to be considered to have the same size as other arrays of the same type parameters (or repr(transparent) wrappers thereof), as long as their element count is the same.

It only supports very limited comparisons, but it opens up more safe and legal transmutes than were previously allowed.

In particular, it allows for transmutes like:

fn make_array<T, const N: usize>() -> [T; N] {
    let mut values: [MaybeUninit<T>; N] = unsafe { MaybeUninit::<[MaybeUninit<T>; N]>::uninit().assume_init() };
    // [... Init values]
    std::mem::transmute(values)
}

which are currently not allowed because [T; N] isn't considered to have the same size as [MaybeUninit<T>; N]

Fixes #61956.

[rust-highfive]

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

[bstrie]

1. repr(transparent) types to be considered to have the same size as the Sized type they wrap.
2. Arrays of type parameters (or repr(transaprent) wrappers thereof) to be considered to have the same size as other arrays of the same type parameters (or repr(transparent) wrappers thereof), as long as their element count is the same.

@RalfJung , you seemed to be in favor of allowing such transmutes in #61956 , are you still of the opinion that it should be sound to expand transmutation with the rules described above?

[RalfJung]

Seems reasonable to me but I'd recommend t-lang FCP for changes like this.

[Lokathor]

Note: Strictly speaking transmute_copy can already also do this.

[varkor]

Reassigning to r? @RalfJung, who is more familiar with the nuances here.

[RalfJung]

@varkor I might be familiar with the nuances of at the bigh level here, but I am completely unfamiliar with the nuances of the code that is being changed here.^^ I don't think I can review that, I am afraid.

But I'll nominate this for lang team discussion. Cc @rust-lang/lang

[RalfJung]

Maybe something like RepeatedTy or so would make more sense? The current name doesn't really convey a lot of meaning.

[scottmcm]

Personally I'm torn here. On one hand, I think this would be quite useful. On the other hand, I worry that this might make it harder to make transmute non-magic.

Maybe someone from the const WG has an idea about whether this would make it harder to encode the "sizes are the same" check as a "real" type system predicate instead of intrinsic magic?

For the specific example in the OP, one way forward would be to just stabilize https://doc.rust-lang.org/nightly/std/mem/union.MaybeUninit.html#method.array_assume_init (or something like it).

[RalfJung]

From the implementation side, maybe @nikic or @nagisa could review this?

[nagisa]

r? @nagisa yeah, I can review the implementation but before I spend time on this please make a decision at T-lang level that this is a desirable change in the first place.

[joshtriplett]

Dropping I-nominated; @scottmcm to write up a consensus from lang-team discussion.

[scottmcm]

We discussed this in the 07-20 lang team meeting, and the consensus was to not move forward with this.

The core of the concern here is that it felt like it was overlapping with the safe transmute work. Not a 100% overlap, of course, but that there are primitive features which that project will be adding that could be leveraged here in a way that's less ad-hoc. And this change brings up a bunch of the same visibility/coherence questions that that project is tackling, like how changing a private field from u32 to NonZeroU32 could become a compilation-breaking change if people are transmuting values of the type (as opposed to a "it was always UB, just possibly not caught previously" runtime problem).

For now we'd like to see #61956 fixed without encouraging transmute, probably by a method like in #80908.

(Spitballing without my lang hat on: safe transmute will know that [T; N] -> [MaybeUninit<T>; N] is fine, so maybe there's space for a still-not-safe but less-yolo transmute for the other direction.)