Tracking issue for #[repr(align(x))] on enums

[niklasf]

RFC 1358 introduced #[repr(align(x))] on structs (and unions). It mentions:

Custom alignment can only be specified on struct declarations for now. Specifying a different alignment on perhaps enum or type definitions should be a backwards-compatible extension.

It would be a nice convenience to allow this for enums, especially when they are part of a public API.

#[repr(align(x))]
enum Foo {
    // ...
}

would be equivalent to using AlignX<Foo> everywhere:

#[repr(align(x))]
struct AlignX<T>(T);

enum Foo {
    // ...
}

[cramertj]

This compiles today:

#![feature(repr_align_enum)]

#[repr(align(1))]
enum X { X(u64) }

fn main() {
    match &X::X(5) {
        X::X(x) => println!("{:?}", x),
    }
}

I would expect this to be an error-- references to u64 require more than align(1).

[hanna-kruppe]

repr(align(N)) raises the alignment to N, but has no effect if the alignment is already >= N without the annotation (in particular it doesn't lower the alignment or error). Or in other words, it ensures a certain minimum alignment. This is not specific to enums, it works the same for structs and unions. I also think this is intentional, though I can't find mention of it in the RFC at a glance (but in any case I think it's the most sensible semantics -- though perhaps there should be a lint).

[cramertj]

Got it-- it's surprising to me that we wouldn't at least warn on a #[repr(align(X))] attribute that doesn't have any affect (doesn't raise the alignment).

[Centril]

@cramertj Seems like something we could tuck into the unused_attributes lint? cc @oli-obk

[oli-obk]

The effect of the attribute is platform dependent. I don't see how we could make this lint free of false positives. We could add something like it to clippy, but as a rustc lint that is always on, false positives are essentially never accepted.

Suggesting #[cfg_attr(not(current_platform), repr(align(X)))] is possible, technically correct on all platforms, but still seems like it's just noise to me.

[hanna-kruppe]

We clearly shouldn't lint for things like #[repr(align(8))] struct Ptr(*const u32) on 64 bit platforms. Deciding where to draw the line (let alone implement that) is difficult to decide in general, but we could approximate it coarsely and conservatively, i.e., err on the side of false negatives. For example, we could try to estimates (edit:) minimum alignment across all plausible target platforms today and only say something if that's possible and the requested alignment is below even that.

[oli-obk]

If that can be done as you describe, adding it to unused_attributes lint sounds great!

[cramertj]

Okay-- I'm excited about the idea of an unused_attribute lint for this. However, seeing as this is already an issue on stable with #[repr(align(X))] on structs, I don't think we should block stabilization of this feature on the lint, and I think that the rest of @rust-lang/lang agrees. I believe @Centril is planning to write up a stabilization proposal.

[Centril]

Stabilization PR and proposal up in #61229.
After landing it we will need to slightly adjust the reference before closing this issue.