make the core::raw struct representation defined

[thestinger]

Closes #18313

[sfackler]

I don't see why this is necessary. These structures are guaranteed to match whatever the compiler decides to represent their related built-in types as. It's the compiler's responsibility to make sure that it does the right thing with the resulting layout of these types. What does that have to do with a C-ABI equivalent layout?

[thestinger]

@sfackler: The layout is entirely implementation defined. The compiler can use a different representation for struct Foo(u32, u64) and struct Bar(u32, u64). It was done with the intent of allowing features like struct randomization.

[thestinger]

The standard library is incorrect whenever it relies on the compiler to order the fields in a certain way. It defines these built-in types as having a specific order / layout which is what #![repr(C)] is for.

[sfackler]

I am aware of implementation defined layout. It's true in general that libraries can't depend on the result of undefined layout. However, these types exist to specify the otherwise unspecified layout of builtin types. They already directly rely on implementation details of the compiler, and will continue to do so even if they're tagged with #[repr(C)].

[cgaebel]

@sfackler It's also for people like me who want the representation of Vec and Slice to be the same, to allow for branch-free conversion from one to the other. See: #18303

[thestinger]

@cgaebel: That's not why I'm marking them this way.

[cgaebel]

Then why are you? As long as the layouts match what the compiler generates, it shouldn't be a problem to re-order.

[thestinger]

@sfackler: They need to be marked with #[repr(C)] because otherwise the compiler will reorder the fields when a feature like struct randomization is used. The implementation currently uses the C representation for all structs but code relying on that has UB and needs to be fixed. It is blocking the implementation of features taking advantage of the implementation-defined representation.

[thestinger]

@sfackler: The fact that it's implementation defined does not mean that it will represent struct Foo(u32, u64) and struct Bar(u32, u64) in the same implementation-defined way. It means it is free to choose a different representation for both of those structures. The ability to randomize struct layout was part of the rationale laid out in the RFC.

[thestinger]

@cgaebel: It will not match what the compiler generates when struct randomization is used. It has a chance of matching the representation. Any code using these has undefined behaviour and is blocking the implementation of the features laid out in the RFC.

[sfackler]

If randomized struct layout is implemented, is there any reason we wouldn't want to randomize layout of [u8] etc? Should these be tagged #[repr(C)] or should they be made lang items?

[thestinger]

@sfackler: It's think we would eventually want to randomize the layout of built-in types. However, I think the layout of those types is considered well-defined right now. There's a lot of low-level Rust code in the wild depending on the order and I think it would require an RFC amendment extending it to certain built-in types rather than just struct.

[thestinger]

(this is just intended to be make it well-defined today and unblock implementing randomization)

[sfackler]

Cool, SGTM.