Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How transitive is repr(transparent)? #486

Open
Manishearth opened this issue Dec 21, 2023 · 11 comments
Open

How transitive is repr(transparent)? #486

Manishearth opened this issue Dec 21, 2023 · 11 comments

Comments

@Manishearth
Copy link
Member

Context: hyperium/hyper#3500

repr(transparent) makes types have the same representation/ABI. Does it have the same effect on generic types containing it?

For example, in the following case:

enum Generic<T> {
   Type(T),
   TwoType(T, T),
   String(String),
   Nothing
}

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

is it safe to transmute between Generic<T> and Generic<Wrapper<T>>? Do they have the same ABI? I'm thinking about things like -Zrandomize-layout.

@RalfJung
Copy link
Member

RalfJung commented Dec 22, 2023

Do they have the same ABI?

No.

is it safe to transmute between Generic<T> and Generic<Wrapper<T>>?

I think that s the intention; I don't know if it actually follows from anything we document. I also don't know what -Zrandomize-layout does here.

@Manishearth
Copy link
Member Author

Probably worth documenting somewhere.

I suspect -Zrandomize-layout doesn't respect this, but that's fine, it's not a perfect representation of the rules.

@RalfJung
Copy link
Member

That would make randomize-layout unsound though, which is clearly a bug. So I don't think it's "fine".

@digama0
Copy link

digama0 commented Dec 22, 2023

I don't think we promise that Generic<T> and Generic<Wrapper<T>> are the same. In general we can't do this, because of associated types. Maybe we can carve out some subset of cases for which it is okay, but I don't think that -Zrandomize-layout is doing anything unsound currently.

@RalfJung
Copy link
Member

RalfJung commented Dec 22, 2023

The question (as I understood it) was for this specific type, which doesn't use associated types. Obviously there are limits to this.

@digama0
Copy link

digama0 commented Dec 22, 2023

We definitely don't promise this, and randomize-layout may be laying them out differently. I don't think this is particularly desirable, but repr(Rust) structs have basically no layout guarantees.

@Manishearth
Copy link
Member Author

Manishearth commented Dec 22, 2023

That would make randomize-layout unsound though, which is clearly a bug. So I don't think it's "fine".

Oh sure I meant that I wouldn't be surprised and I wouldn't treat it as a strong expectation of what the semantics should be.

@FeldrinH
Copy link

FeldrinH commented Apr 15, 2024

Do they have the same ABI?

No.

I read through the linked document and could not find anything that states that the answer is no. What am I missing?

@RalfJung
Copy link
Member

The answer is always "no" except when the linked document states otherwise. So the fact that none of the cases there says they are compatible implies that they are not compatible.

@FeldrinH
Copy link

The answer is always "no" except when the linked document states otherwise. So the fact that none of the cases there says they are compatible implies that they are not compatible.

The document does not seem to discuss ABI compatibility of structs at all. Does that mean that two different structs are never ABI compatible?

@RalfJung
Copy link
Member

RalfJung commented Apr 15, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants