RFC: Add #[repr(pack = "N")]

[retep998]

Rendered

[emberian]

s/otherwise//

[emberian]

Please remove this paragraph.

[emberian]

This must be resolved. Verify against the behavior of clang (or gcc).

[retep998]

Specifically clang or gcc on a platform other than Windows. On Windows they are supposed to match the msvc ABI.

[emberian]

The feature is necessary. If this behavior is in line with common C compilers,

[emberian]

s/effectivally/effectively/

[DanielKeep]

For reference, here's an example of Clang doing this.

[retep998]

See this comment for an interesting interaction edge case with the alignment RFC regarding required alignment.

[nikomatsakis]

Hear ye, hear ye! This RFC is now entering final comment period.

[strega-nil]

This seems right to have. I think the best is #[repr(packed(1))] or #[repr(packed = "1")]. So the default of #[repr(packed)] would be #[repr(packed(1))].

[solson]

@ubsan #[repr(packed(1))] is not currently valid attribute syntax (but #[repr(packed = "1")] is). I guess the RFC mentions this, so cc @retep998 as well.

It could become valid with #1559, though, or as @nrc mentions in a comment, the procedural macros RFC.

[retep998]

I don't mind the syntax either way, as long as I can have this attribute at all.

[starkat99]

I think it should just extend #[repr(packed)] rather than adding a new pack syntax. The duplication is confusing otherwise. Just have #[repr(packed)] be default to #[repr(packed = "1")].

[nikomatsakis]

Hmm, I think I too prefer #[repr(packed = "N")]. Otherwise, the RFC seems unobjectionable to me. It'd also be nice to approve #1358, which covers very similar subject matter.

[nikomatsakis]

One area the RFC did not (explicitly) address -- or I missed it -- is what to do if there are multiple packed specifiers. It did say that #[repr(pack = "2")] and #[repr(packed)] cannot be combined, but it did not say anything about #[repr(pack = "2")] and #[repr(pack = "4")]. Presumably this is an error as well? (Unlike the proposed align RFC?)

Is there any reason one might want multiple specifiers? Like, independent macros might add tighter and tighter requirements? (However, unlike with alignment, it's not obvious to me whether you would want the max or min packing that was specified.)

[retep998]

I think if we did allow specifying the packing multiple times, that the right thing to do would be to use the smallest packing specified. The alignment of any given field is min(default, packing) so extending packing to be min(packing1, packing2) seems fairly natural.

As for the align RFC, there'd need to be a decision on how it interacts with packing. Whether it does the msvc style __declspec(align(N)) with required alignment that cannot be lowered by packing, or the gcc style alignment attribute that can be lowered by packing.

[nikomatsakis]

Huzzah! The @rust-lang/lang team has decided to accept this RFC, with the caveat that the attribute be renamed to packed (and not pack). I will make this change when merging (I assume @retep998 you do not object.)

We discussed a few other things:

• We should (obviously) clarify the relationship to an align attribute. We're going to bring the align RFC into FCP, discussion can happen there. But in the @rust-lang/lang meeting, I think the general feeling was that if both attributes are present, then the specified align would overrule the alignment derived from packing (in other words, we would match the MSVC style). Another option is to forbid both options from being used simultaneously, but that seems unnecessary to me.

[nikomatsakis]

Tracking issue: rust-lang/rust#33158

If you'd like to keep following the development of this feature, please subscribe to that issue, thanks! :)