How far does repr(transparent)'s transparentness stretch in repr(Rust)?

[Manishearth]

As I understand it, generally two otherwise identical Rust type definitions (e.g. struct Foo(u8, usize), struct Bar(u8, usize)) do not need to produce transmutable types, trivially shown by using -Zrandomize-layout with identically defined structs with a couple fields.

However, of course (u8, usize) and (u8, usize) can be transmuted, after all, they are the same type. The same goes for Generic<u8> and Generic<u8>.

What if we have #[repr(transparent)] struct Wrap(u8);: Are (Wrap, usize) and (u8, usize) transmutable?

What about Generic<u8> and Generic<Wrap> where Generic is some generic struct?

How far does repr(transparent) stretch in its equivalency when the transparent type is used as a field elsewhere?

[burdges]

NonZero is repr(transparent) but Option<NonZero<usize>> differs from Option<usize>
https://github.com/rust-lang/rust/blob/main/library/core/src/num/nonzero.rs#L124

And repr(transparent) types could increase the alignment too.

[Manishearth]

Good point. What can we rely on here? Anything?

It might be nice to have some guarantees, especially in the common case of "repr transparent with no other special behavior".

[burdges]

You could classify types by how they exploit the inner representation, so different niche systems, alignment, and not sure what else. You could then say repr(transparent) types behave the same when used in the same class of outer type, but..

If I have a type that winds up being { data1: [u8;3], _padding: [u8;U-3]: data2: usize } where U is the usize width, then how can rust use _padding for the outer type? This seems like a way to get really a lot of different repr that wreck your classification.

The usual situation is transmutes of Arcs, Mutexs, and similar, so the siple answer would be to note some specific outer types cannot cause troubles. Arc<Option<T>> would not however be a non-problematic outer type, even though Arc<T> is non-problematic.

[Manishearth]

I think Option can get away with being "non problematic" if we pick a definition of "truly transparent" that covers things like nonzero.

[RalfJung]

Currently, I don't think we make any guarantees for these cases. Making more guarantees here is mostly a matter of carving out a suitable subset and bringing it to t-lang for stabilization; I am not aware of any opsem questions in this area.

[Manishearth]

Fair enough!

I think a rough design would define "fully transparent" as repr(transparent) with no other layout attributes (where layout attributes include alignment and niche ones). And then we can either:

• Define repr(Rust) Foo<A> and Foo<B> as guaranteed as having the same layout (and being fully transparent) if A is fully transparent over B.
• Just define this property for tuples.

I'll bring it up with T-lang.

[programmerjake]

we'll need to exclude code like:

trait Trait {
    type Type;
}

pub struct S<T: Trait>(T::Type);

#[repr(transparent)]
pub struct Transparent<T>(T);

impl Trait for u8 {
    type Type = u8;
}

impl Trait for Transparent<u8> {
    type Type = String;
}

// now S<u8> and S<Transparent<u8>> are not ABI compatible

[Manishearth]

Ah, good point

[CAD97]

We do already necessarily have a guarantee that for a repr-stable containing type, changing fully transparent field types must not change the containing type's representation.

Specifying this guarantee for Generic<u8> and Generic<Wrap> but not two concrete types with equivalent fields seems non-straightforward. My attempt would be

Two types are considered repr-equal if:

• They are the same type;
• Either type is #[repr(transparent)] with no other attributes that impact representation, and its underlying type is repr-equal to the other type;
• Both types have a stable representation, and their stable representations are equivalent; or
• Both types are instantiations of the same generic type stem, and between both:
  • All const generic binders are equal,
  • All type generic binders are repr-equal, and
  • All field types are repr-equal (after generic instantiation).

Types that are repr-equal are guaranteed to be layout and ABI compatible.

As for how to actually implement this in a way that it remains true even with randomized layouts and even if the randomization fuel runs out between the instantiation of different repr-equal, very roughly speaking, generic types' repr would need to be keyed off of the mangled type name after normalizing generic types to their fully-transparent base type along with its fields' types with the same normalization (instead of just the mangled type name).

[Manishearth]

Yeah, that's similar to what I was considering. I wasn't thinking about const generics but my own definition provided a way to compute a "skeleton" for hashing reprs:

Type A is definitionally repr-equal to type B if A is repr(transparent) over B with no other attributes that impact representation. Note that this is a unidirectional property.

Two fully instantiated types are repr-equal if they have the same repr-skeleton.

• The repr skeleton of a struct that is definitionally repr-equal to another struct is the repr skeleton of that other struct
• The repr-skeleton of a monomorphized struct is the mangled name of the struct, without generics, followed by an ordered list of fields containing the repr skeletons of each sub field
• The repr skeleton of a monomorphized enum is the mangled name of the enum, without generics, followed by an ordered(?) list of variants containing the repr skeletons of each variant field (ordered).
• The repr skeleton of a tuple is an ordered list of repr skeletons of the subfields.
• The repr skeleton of all slice types and &str is that of &[u8].
• The repr skeleton of a type with stable representation is the specification of that stable representation (size + alignment)
• There's probably more here.

(I'm defining these skeletons as stringy but it is easy to represent them as a typed concept)