r226653 - AST: Don't ignore alignas on EnumDecls when calculating alignment

[Justin Bogner]

David Majnemer <david.majnemer at gmail.com> writes:
> On Wed, Jan 21, 2015 at 9:06 AM, Justin Bogner <mail at justinbogner.com> wrote:
>> David Majnemer <david.majnemer at gmail.com> writes:
>>> enum Y : int;
>>> Y y;
>>>
>>> typedef int __attribute__((aligned(64))) u;
>>> enum Y : u {};
>>>
>>> What is the alignment of 'Y'?  It would be more consistent with the
>>> overall design of enums with fixed underlying types to consider the
>>> underlying type's UnqualifiedDesugaredType.
>> Is it more consistent?
>
> I think so.
>
> The standard forbids:
> typedef int alignas(16) Ty;
> enum : int alignas(4) {};
>
> we error with: 'alignas' attribute cannot be applied to types
>
> The standard is pretty clear that alignment isn't a property of types.
>
> We would also match the behavior of MSVC and ICC, they also ignore the
> alignment of the underlying type.

Fair enough.

>> What about the case without the forward
>> declaration, or if the forward declaration also specifies the alignment?
>
> Then what do we do with:
>
> typedef int __attribute__((aligned(8))) Ty1;
> typedef int __attribute__((aligned(16))) Ty2;
>
> enum alignas(16) : Ty1 {};
> enum alignas(8) : Ty2 {};
>
> What alignment would Ty1 and Ty2 have? The max of all possible alignments?
> Just the alignment on the EnumDecl?
>
>> It's not really clear what the programmer's intent is in these cases
>> anyway, maybe we could warn that they seem to be doing something silly?
>
> I think a warning would be a fine idea.

PR22290.