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.

Sign up for GitHub

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

Jump to bottom

[RFC] Allow packed types to transitively contain aligned types #3718

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
+197 −0
Open

[RFC] Allow packed types to transitively contain aligned types #3718

Changes from all commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
8518173
Initial writeup
Neo-Zhixing Oct 24, 2024
3d44198
Update PR numbers
Neo-Zhixing Oct 24, 2024
e77c6be
update
Neo-Zhixing Oct 24, 2024
af3cc30
Update
Neo-Zhixing Oct 25, 2024
175d29f
Updates
Neo-Zhixing Oct 29, 2024
a53aab1
Updates
Neo-Zhixing Oct 29, 2024
5190399
Update text/0000-layout-packed-aligned.md
Neo-Zhixing Nov 4, 2024
a12370d
Update drawbacks
Neo-Zhixing Nov 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
197 changes: 197 additions & 0 deletions text/0000-layout-packed-aligned.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,197 @@
- Feature Name: `layout_packed_aligned`
- Start Date: 2024-10-24
- RFC PR: [rust-lang/rfcs#3718](https://github.com/rust-lang/rfcs/pull/3718)
- Rust Issue: [rust-lang/rust#100743](https://github.com/rust-lang/rust/issues/100743)

# Summary
[summary]: #summary

This RFC makes it legal to have `#[repr(C)]` structs that are:
- Both packed and aligned.
- Packed, and transitively contains`#[repr(align)]` types.

It also introduces `#[repr(system)]` which is designed for interoperability with operating system APIs.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it's be worth splitting this out.

I'm a big fan of splitting repr(linear) vs repr(C) (which I think this is spelling as repr(C) vs repr(system)) to have the distinction between "the layout you get with https://doc.rust-lang.org/beta/std/alloc/struct.Layout.html#method.extend" and "whatever weird layout your C compiler uses". That distinction would be really nice for making intent clearer, since today you get "you can't do that in C" warnings sometimes just because you used repr(C) to have a predictable layout for your Rust-only code.

So I'd kinda like to consider that separately from any new packed-related stuff.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the only difference between #[repr(C)] and #[repr(system)] by this RFC is that on pc-windows-gnu #[repr(system)] is the MSVC layout while #[repr(C)] is the GCC layout. On all other targets #[repr(system)] and #[repr(C)] are identical (per this RFC).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think repr(linear) is independently useful and we should have all 3. that said, I am concerned that current repr(C) code often means "I want stable linear layout" rather than "I want whatever weirdness the C compiler decides to use", so I think deprecating repr(C) and replacing it with repr(linear), repr(bikeshed_other_C) and repr(system) is worth considering.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, this RFC proposes a different distinction between repr(C) and repr(system) than what has been previously discussed in other threads.

Since the distinction between the two layouts we have here is Windows-only, I wonder if it should be some Windows-only name, like repr(msvc) or so? Is there a good reason to even make both of them available on all targets -- effectively exporting a Windows-only complication to other, saner platforms?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a good reason to even make both of them available on all targets

The reason is that this is also how the extern "system" function ABI string works. Code uses extern "system" to link to libraries which use __stdcall on Windows platforms, and in the same way code would use #[repr(system)] for linking to a dylib which provides builds with only the MSVC toolchain for Windows targets.

I don't necessarily endorse this option, but it is logically consistent with how Rust already uses "system" as an ABI string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was previously forbidden but the check has some gaps, so this can impact existing code.

It also breaks existing code that assumes that all repr(C) types are laid out according to the rules described here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason is that this is also how the extern "system" function ABI string works. Code uses extern "system" to link to libraries which use __stdcall on Windows platforms, and in the same way code would use #[repr(system)] for linking to a dylib which provides builds with only the MSVC toolchain for Windows targets.

From what I understand, extern "system" is the same on MSVC and GNU Windows targets? So this is IMO a false analogy then, making it more confusing than if we instead use a name that more explicitly represents that Windows has two ABIs, which we support with two target triples, and you might want to write code that talks with the "other" ABI.

Speaking of which, how would a program for the MSVC target lay out its type in the right way to call a GNU ABI library? That does not seem possible with this proposal.

Copy link

@CAD97 CAD97 Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, extern "system" is extern "stdcall" on all Windows targets. Just like how this RFC makes repr(system) on both windows-msvc and windows-gnu behave as repr(MS). The difference is repr(C), which switches between msvc/gnu respectively.

Copy link
Member

@RalfJung RalfJung Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh okay, I mixed up which is C and which is system then.

Just like how this RFC makes repr(C) on both windows-msvc and windows-gnu behave as repr(MS).

The first repr in that sentence should be system, not C, right?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, yes, that's correct.

It has the same behavior as `#[repr(C)]` except on `*-pc-windows-gnu` targets where it uses the msvc layout
rules instead.

# Motivation
[motivation]: #motivation

This RFC enables the following struct definitions:

```rs
#[repr(C, packed(2), align(4))]
struct Foo { // Alignment = 4, Size = 8
a: u8, // Offset = 0
b: u32, // Offset = 2
}
```

This is commonly needed when Rust is being used to interop with existing C and C++ code bases, which may contain
unaligned types. For example in `clang` it is possible to create the following type definition, and there is
currently no easy way to create a matching Rust type:

```cpp
struct __attribute__((packed, aligned(4))) MyStruct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is somewhat confusing that the Rust example uses packed(2) but the C example just uses packed. Would be better to make them equivalent.

uint8_t a;
uint32_t b;
};
Neo-Zhixing marked this conversation as resolved.
Show resolved Hide resolved
```

Currently, `#[repr(packed(_))]` structs cannot be `#[repr(align(_))]` or transitively contain `#[repr(align(_))]` types. Attempting to do so results in a [hard error](https://doc.rust-lang.org/nightly/error_codes/E0588.html).

This behavior was added in the [original implementation](https://github.com/rust-lang/rust/issues/33158) of `#[repr(packed)]` due to concerns over differing behavior between msvc and gcc/clang. This makes it cumbersome or even impossible to produce C-compatible struct layouts in Rust when the corresponding C types were annotated with both `packed` and `aligned`.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

## `#[repr(C)]`
When `align` and `packed` attributes exist on the same type, or when `packed` structs transitively contains `align` types,
CAD97 marked this conversation as resolved.
Show resolved Hide resolved
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any difference in behavior between the c, system, and rust for types with both packed and align?

My expectation would be that regardless of whether it is c, system, or rust, if I have repr(packed(2),align(4)) the alignment of the overall type is 4, and the alignment of it's fields is at most 2 unless maybe one of those fields itself has an alignment specified. My reading of the reference section agrees with that, but the guide section is a little ambiguous.

And FWIW, it would be more intuitive to me if packed ignored the alignment of field types, but had a way to specify higher alignment for individual fields.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As currently written, #[repr(align)] used in a field's type definition (or transitively in its fields' types') could still raise the alignment of the type beyond the minimum alignment provided by the attribute, if the "infectious" alignment is in use (MSVC layout).

In MSVC C, such would theoretically be a compilation error (alignas cannot be used to lower alignment). I don't know what the behavior of templated C++ is, actually.

This is consistent with the behavior of repr(align) for an alignment less than the alignment required for primitive field alignment.

the resulting layout matches the target toolchain ABI.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To verify, Clang/LLVM does replicate the MSVC behavior correctly for its MSVC target, correct? It's a harder sell to change repr(C) if extended types already weren't portable between the C++ compiler toolchains for the target.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do believe so.

https://clang.llvm.org/docs/MSVCCompatibility.html

First, Clang attempts to be ABI-compatible, meaning that Clang-compiled code should be able to link against MSVC-compiled code successfully.

Record layout: Complete. We’ve tested this with a fuzzer and have fixed all known bugs.


For example, given:
```c
#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);
```
`align_of::<Bar>()` would be 4 for `*-pc-windows-msvc` and 1 for everything else.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is extremely unintuitive behavior, especially for those of us writing custom derives (like zerocopy). We can't just rely on querying align_of - we need to be able to parse a type's definition and understand the semantics of any repr attributes on it.

Also, while this is technically not a breaking change, I wouldn't be surprised if some custom derive code implicitly assumes that this behavior isn't possible, and would become unsound in the face of this change. For example, as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change.

I'd propose that if system-specific behavior like this is required, it'd be better to do it behind a new repr so that the behavior of repr(C) remains straightforward.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change

Did you say this wrong somehow? By this RFC, align(N) types are still always aligned to at least N when behind a reference. In fact, they're aligned to N in more cases, as packed types can't underalign them with MSVC layout rules.

What changes is that packed(M) types no longer have an alignment of exactly M, but instead have an alignment of at least M.

custom derive code might be unsound

Such custom derive code is already likely quite iffy, since #[derive(Trait)] #[proc_macro] struct will have the derive see the token stream before the proc macro processes it and can modify all the decorated code arbitrarily. zerocopy is aware of this and doesn't permit any attribute it doesn't know the reserved semantics of to be in the type definition, but that's a high, difficult, and restrictive bar to clear most of the time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as it stands today, it is valid to assume that a #[repr(align(N))] type has alignment at least N, but that would stop being valid with this change

Did you say this wrong somehow? By this RFC, align(N) types are still always aligned to at least N when behind a reference. In fact, they're aligned to N in more cases, as packed types can't underalign them with MSVC layout rules.

What changes is that packed(M) types no longer have an alignment of exactly M, but instead have an alignment of at least M.

You're right, I misread the text. Still, there's a concern: Our derives currently take #[repr(C, packed(N))] as a guarantee that the decorated type cannot have alignment greater than N. This is consistent with the Reference:

For packed, ... the alignments of each field, for the purpose of positioning fields, is the smaller of the specified alignment and the alignment of the field’s type.

IIUC, to make packed no longer provide this guarantee is a breaking change with respect to the Reference.

There's another concern as well: This makes "whether or not the type has an alignment repr (packed/align)" part of the type's layout. The Reference currently specifies how types are laid out purely in terms of the sizes and alignments of their field types, and not in terms of any other facts about the field types. With this change, the following two Bar types would have different layouts despite containing Foo types with identical sizes and alignments:

#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);

#[repr(C)]
struct Foo(u8, [u32; 0]);
#[repr(C, packed(1))]
struct Bar(Foo);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

#[repr(C, align(4))]
struct Foo(u8);
#[repr(C, packed(1))]
struct Bar(Foo);

This does not compile today (reference said "a packed type cannot transitively contain another aligned type"), so we are free to choose whether the two Bars should have same or different layouts after this RFC.

error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type
 --> src/lib.rs:4:1
  |
4 | struct Bar(Foo);
  | ^^^^^^^^^^
  |
note: `Foo` has a `#[repr(align)]` attribute
 --> src/lib.rs:2:1
  |
2 | struct Foo(u8);
  | ^^^^^^^^^^

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My point isn't that this is a breaking change, but rather than it breaks the current mental model, which is that a type's layout is determined solely by the size and alignment of its fields. This RFC changes that to say that a type's layout is determined by the size, alignment, and representation of its fields. Since representation is a fairly complicated concept (it can include repr(C), repr(Int), repr(packed), repr(align), repr(transparent), and some-but-not-all combinations of these), IMO it significantly complicates the mental model of type layout to say that a type's layout also depends upon its fields' representations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the existing. mental model turned out to be in contradiction to reality, at least on MSVC targets. When you build a model and then reality demonstrates the incorrectness of the model, sometimes the best option is to fix your model. Yes we documented this model in a bunch of places, but... what else could we do? Stick our head into the sand and continue pretending that the simpler model is "good enough"?

So now the layout of a type is determined by the size, alignment, and explicitly requested alignment of its fields.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, the existing mental model turned out to be in contradiction to reality, at least on MSVC targets. When you build a model and then reality demonstrates the incorrectness of the model, sometimes the best option is to fix your model.

There is another alternative: argue that because __declspec(align) and #pragma pack are nonstandard C extensions, we don't necessarily need to be layout-compatible with the system C in these cases. That's basically the argument for a struct with one zero-length array member on MSVC being zero-sized and not align-sized.

Counter to my own point, though, is that struct alignas(N) Name is standard C*++*, and the MSVC behavior is the same as with declspec in C mode. #pragma pack is still nonstandard (and I find MSVC's definition of it to be bonkers) but standard type alignas significantly weakens the argument that it isn't necessary to support.

But if there exists a type on MSVC with basic alignment higher than the default member packing level without also having an explicitly requested alignment (thus not being sufficiently aligned by default), then I would swing towards writing of MSVC layout edge cases as broken.

This does not compile today

Unfortunately,​ this error is straightforward to sidestep with generics.

#[repr(align(4))]
struct Aligned;

#[repr(packed(1))]
struct Packed<T = Aligned>(T);

fn main() {
    dbg!(align_of::<Packed>());
    // [src/main.rs:8:5] align_of::<Packed>() = 1
}



## `#[repr(system)]`
When `align` and `packed` attributes exist on the same type, or when `packed` structs transitively contains `align` types,
the resulting layout matches the target OS ABI.

For example, given:
```c
#[repr(system, align(4))]
struct Foo(u8);
#[repr(system, packed(1))]
struct Bar(Foo);
```
`align_of::<Bar>()` would be 4 for `*-pc-windows-msvc` and `*-pc-windows-gnu`. It would be 1 for everything else.

## `#[repr(Rust)]`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would someone want this on repr(Rust)? Can we just make it disallowed for repr(Rust)?

(repr(packed) is generally bad, because it affects safe code too, so I'd rather ban it as much as is practical.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do allow standalone packed and aligned attributes for repr(Rust), so I do believe that it is a good idea to enable nested packed and aligned attributes as well so that the language design seems more coherent. So I'm inclined to allow it unless we have a good reason not to.

When `align(N)` and `packed(M)` attributes exist on the same type, or when `packed` structs contain `aligned` fields,
the type will have their base alignment increased to `N`, while the struct fields will be laid out as if their
alignments were decreased to `M`. However, in general Rust is free to reorder
these fields for optimization purposes, and the only guarantee is that the fields will maintain a minimum alignment of `M`.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

In the following paragraphs, "Decreasing M to N" means:
```
if M > N {
M = n
}
```

"Increasing M to N" means:
```
if M < N {
M = N
}
```


`#[repr(align(N))]` increases the base alignment of a type to be N.

`#[repr(packed(M))]` decreases the alignment of the struct fields to be M. Because the base alignment of the type
is defined as the maximum of the alignment for any fields, this also has the indirect result of decreasing the base
alignment of the type to be M.

When the align and packed modifiers are applied on the same type as `#[repr(align(N), packed(M))]`,
the alignment of the struct fields are decreased to be M. Then, the base alignment of the type is
increased to be N.

When a `#[repr(packed(M))]` struct transitively contains a field with `#[repr(align(N))]` type, depending on the
target triplet, either:
Copy link
Member

@RalfJung RalfJung Oct 31, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should IMO be rephrased as an algorithm that works one "layer" at a time. Computing the layout of a type T should only consider the fields of T and their properties. It should never recurse into the fields of T.

I don't currently actually understand the proposed spec here, and this should make it a lot easier to understand.

I suspect what will happen is that as part of this, we will have to introduce a new property of T that is "bubbled up" in the recursion -- a new degree of freedom that was not required so far. (@CAD97 has already alluded to this elsewhere.) Identifying and clearly describing this property will make it a lot easier to understand the resulting layout algorithm.

Copy link
Member

@RalfJung RalfJung Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My current understanding of the algorithm is as follows:

We equip types with a new property, the "explicitly requested alignment". For all base types, this alignment is 1. For structs, it is by default the maximum of the explicitly requested alignments of all fields. For a struct with the #[repr(align(N))] attribute, the explicitly requested alignment the maximum of N and the explicitly requested alignments of its fields.

Note that the explicitly requested alignment of a type can never be bigger than the required alignment of the type.

When computing the layout of a packed(P) struct, then currently we ensure each field is aligned to min(A, P), where A is the (regular) alignment of the field type. Under the new rules, only on MSVC targets, we instead ensure the field is aligned to max(E, min(A, P)), where E is the explicitly requested alignment. (Due to the aforementioned inequality, this is equivalent to min(max(E, P), A). Also, in particular the packed struct has at least this alignment itself.) This is the only time the explicitly requested alignment of a type has any effect.

I am not fully confident that this is correct. Here's a corner case:

#[repr(C, align(4))]
struct Align4(i32);

#[repr(C, align(2))]
struct Align2(Align4);

#[repr(C, packed)]
struct Packed(Align2);

What is the resulting alignment of Packed on MSVC? My proposed algorithm says 4. Is that correct?

Copy link
Member

@RalfJung RalfJung Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another corner case:

#[repr(C, align(4))]
struct Align4(i32);

struct Group(u8, Align4);

#[repr(C, packed)]
struct Packed(u16, Group);

What does the resulting layout of Packed look like? My algorithm says:

  • field 0 (type u16): offset 0
  • field 1 (type Group): offset 4
    • nested field 0 (type u8): offset 4 (relative to the beginning of Packed)
    • nested field 1 (type Align4): offset 8

Is that correct?

Copy link
Member

@RalfJung RalfJung Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The post this referred to has since been deleted.)

Oh, so having an align attribute on a struct where a field already has a higher explicitly requested alignment is an error? Should this also be an error in Rust? The RFC doesn't say so, and it would be a breaking change... but that should at least be mentioned in the RFC. It might be worth a warning if someone writes a repr(C) type in Rust that couldn't be written in C.

Copy link

@CAD97 CAD97 Nov 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://c.godbolt.org/z/es1cGPhz9

On MSVC 19.40 (VS 17.10) in C mode,

#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

__declspec(align(4))
struct Align4
{
    int32_t _0;
};

__declspec(align(2))
struct Align2
{
    struct Align4 _0;
};

#pragma pack(push, 1)
struct Packed
{
    struct Align2 _0;
};
#pragma pack(pop)

struct Group
{
    uint8_t _0;
    struct Align4 _1;
};

#pragma pack(push, 1)
struct P
{
    uint16_t _0;
    struct Group _1;
};
#pragma pack(pop)

int main()
{
    printf("alignof(Packed) = %zu\n", alignof(struct Packed));
    printf("\n");
    printf("offsetof(P, _0) = %zu\n", offsetof(struct P, _0));
    printf("offsetof(P, _1) = %zu\n", offsetof(struct P, _1));
    printf("offsetof(P, _1._0) = %zu\n", offsetof(struct P, _1) + offsetof(struct Group, _0));
    printf("offsetof(P, _1._1) = %zu\n", offsetof(struct P, _1) + offsetof(struct Group, _1));
}

gives

alignof(Packed) = 4

offsetof(P, _0) = 0
offsetof(P, _1) = 4
offsetof(P, _1._0) = 4
offsetof(P, _1._1) = 8

Using alignas/_Alignas on the type (alignas(N) struct Tag) instead of __declspec(align) gives

warning C5274: behavior change: _Alignas no longer applies to the type 'Align4' (only applies to declared data objects)

and results of 1 / 0, 2, 2, 6; fully just ignoring the alignas modifier. Note that standard C does not permit the use of alignas for struct definitions. C++ does. In C++ mode (/std:c++latest, using struct alignas(N) Tag), MSVC gives:

alignof(Packed) = 4

offsetof(P, _0) = 0
offsetof(P, _1) = 4
offsetof(P, _1._0) = 4
offsetof(P, _1._1) = 8

along with a warning:

warning C4359: 'Align2': Alignment specifier is less than actual alignment (4), and will be ignored.

EDIT TO ADD: interesting: in C mode, __declspec(align(2)) struct Align2 gives no warning, but struct __declspec(align(2)) Align2 gives the same warning as in C++ mode. Odd. The standard C compliant way of writing the alignment (alignas on the first data member) also does not warn, in C nor C++ mode.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For completeness, clang does not seem to implement this fully, unless I made a mistake: [godbolt]

#include <stdalign.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>

struct [[gnu::ms_struct]] Align4
{
    alignas(4)
    int32_t _0;
};

struct [[gnu::ms_struct]] Align2
{
    // alignas(2) // error: requested alignment is less than minimum alignment of 4 for type 'struct Align4'
    struct Align4 _0;
};

struct [[gnu::packed]] Packed
{
    struct Align2 _0;
};

struct Group
{
    uint8_t _0;
    struct Align4 _1;
};

struct [[gnu::packed]] P
{
    uint16_t _0;
    struct Group _1;
};

int main()
{
    printf("alignof(Packed) = %zu\n", alignof(struct Packed));
    printf("\n");
    printf("offsetof(P, _0) = %zu\n", offsetof(struct P, _0));
    printf("offsetof(P, _1) = %zu\n", offsetof(struct P, _1));
    printf("offsetof(P, _1._0) = %zu\n", offsetof(struct P, _1) + offsetof(struct Group, _0));
    printf("offsetof(P, _1._1) = %zu\n", offsetof(struct P, _1) + offsetof(struct Group, _1));
}
alignof(Packed) = 1

offsetof(P, _0) = 0
offsetof(P, _1) = 2
offsetof(P, _1._0) = 2
offsetof(P, _1._1) = 6

- The field is added to the struct with alignment decreased to M. The packing requirement overrides the alignment requirement. (This is the case for GCC, `#[repr(Rust)]`, `#[repr(C)]` on gnu targets, and `#[repr(system)]` on non-windows targets.)
- The field is added to the struct with alignment decreased to M and then increased to N. The alignment requirement overrides the packing requirement. (This is the case for MSVC, `#[repr(C)]` on msvc targets, `#[repr(system)]` on windows targets.)

# Drawbacks
[drawbacks]: #drawbacks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to this, this RFC will actually change the layout of some types that are currently accepted on stable, on MSVC targets. That should be discussed as a drawback.


Although [https://doc.rust-lang.org/reference/type-layout.html#the-c-representation](the Rust reference) documents the meaning
of repr(C) quite clearly (types are laid out linearly, according to a fixed algorithm.), when you see `#[repr(C)]` in code,
its meaning can be somewhat ambiguous. When someone puts `#[repr(C)]` on their struct, their intention could be one of three things:
1. Having a target-independent and stable representation of the data structure for storage or transmission.
2. FFI with C and C++ libraries compiled for the same target.
3. Interoperability with operating system APIs.

Today, `#[repr(C)]` is being used for all 3 scenarios because the user cannot create a `#[repr(C)]` struct with ambiguous layout between targets. However, this also means
that there exists some C layouts that cannot be specified using `#[repr(C)]`.

This RFC addresses use case 2 with `#[repr(C)]` and use case 3 with `#[repr(system)]`. For use case 1, people will have to seek alternative solutions such as `crABI` or
protobuf. However, it could be a footgun if people continue to use `#[repr(C)]` for use case 1.

It's worthy to note that while this RFC does require people to stop treating `repr(C)` as a linear layout but rather as an
ABI compatiblity layout, our intention is not proposing a breaking change: `packed` structs are previously banned from
transitively containing `aligned` fields, so in most cases existing `repr(C)` structs will be laid out in exactly the same
way as it did before. However, due to an oversight in the current implementation of the Rust compiler, the restriction
can actuall be
[circumvented](https://github.com/rust-lang/rust/issues/100743#issuecomment-1229343705) using generics. Applications
using this pattern to circumvent the restriction will see a change in the struct layout on MSVC targets.

This RFC alone still doesn't make `repr(C)` fully match the target (MSVC) toolchain in all cases; the known other
divergences are enums with overflowing discriminant and how a field of type [T; 0] is handled. So while this does
improve parity, the reality is that there are still edge cases to keep track of for now. These cases shall be addressed
in future RFCs.



# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

This RFC clarifies that:
- `repr(C)` must interoperate with the C compiler for the target.
- `repr(system)` must interoperate with the operating system APIs for the target.
- Similiar to Clang, `repr(C)` does not guarantee consistent layout between targets.

Alternatively, we can also create syntax that allows the user to specify exactly which semantic to use when packed structs transitively contains aligned fields.
For example, a new attribute: #[repr(align_override_packed(N))] that can be used when the behavior of the child overriding the parent alignment is desired.

#[repr(align(N))] #[repr(packed)] can be used together to get the opposite behavior, parent/outer alignment wins.

Explicitly specifying the pack/align semantic has the drawback of complicating FFI. For example, you might need two different definition files depending on the target.

Therefore, a stable layout across compilation target should be relegated as future work.




# Prior art
[prior-art]: #prior-art

Clang matches the Windows ABI for `x86_64-pc-windows-msvc` and matches the GCC ABI for `x86_64-pc-windows-gnu`.

MinGW always uses the GCC ABI.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there prior art for a compiler that can lay out types both using the Windows ABI and the GCC ABI for code within a single target? If yes, how are they distinguishing the two? If no, why does Rust need this ability?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gcc apparently supports that by using the ms_struct attribute

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that would correspond tom in Rust

  • have repr(C) on win-gnu targets match non-win targets
  • have a separate window-only repr(MS) to ask for the msvc layout

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a more full parallel to extern "ABI", we should also support repr(GCC). Then repr(C) is a sort of alias to repr(GCC) or repr(MS) chosen by the target, like extern "C" is an alias (strongly newtyped) to "sysv64"/"win64" (etc).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang appears to also implement [[gnu::ms_struct]] has an open PR implementing [[gnu::gcc_struct]]


We already have both `C` and `system` [calling conventions](https://doc.rust-lang.org/beta/nomicon/ffi.html#foreign-calling-conventions)
to support differing behavior on `x86_windows` and `x86_64_windows`.


This issue was introduced in the [original implementation](https://github.com/rust-lang/rust/issues/33158) of `#[repr(packed(N))]` and have since underwent extensive community discussions:
- [#[repr(align(N))] fields not allowed in #[repr(packed(M>=N))] structs](https://github.com/rust-lang/rust/issues/100743)
- [repr(C) does not always match the current target's C toolchain (when that target is windows-msvc)](https://github.com/rust-lang/unsafe-code-guidelines/issues/521)
- [repr(C) is unsound on MSVC targets](https://github.com/rust-lang/rust/issues/81996)
- [E0587 error on packed and aligned structures from C](https://github.com/rust-lang/rust/issues/59154)
- [E0587 error on packed and aligned structures from C (bindgen)](https://github.com/rust-lang/rust-bindgen/issues/1538)
- [Support for both packed and aligned (in repr(C)](https://github.com/rust-lang/rust/issues/118018)
- [bindgen wanted features & bugfixes (Rust-for-Linux)](https://github.com/Rust-for-Linux/linux/issues/353)
- [packed type cannot transitively contain a #[repr(align)] type](https://github.com/rust-lang/rust-bindgen/issues/2179)
- [structure layout using __aligned__ attribute is incorrect](https://github.com/rust-lang/rust-bindgen/issues/867)


# Unresolved questions
[unresolved-questions]: #unresolved-questions

None for now.


# Future possibilities
[future-possibilities]: #future-possibilities

People intending for a stable struct layout consistent across targets would be directed to use `crABI`.