[PATCH] Sema: When merging typedefs, handle records before merging attributes

Richard Smith richard at metafoo.co.uk
Mon Oct 7 15:49:13 PDT 2013


On Mon, Oct 7, 2013 at 3:09 PM, Justin Bogner <mail at justinbogner.com> wrote:

> Richard Smith <richard at metafoo.co.uk> writes:
> > This doesn't look right in the case where the attribute is on a typedef
> > defined inside a class in C++. Instead, I think we should only perform
> the
> > merging if Old was a TypedefNameDecl.
>
> I think you meant to say "if old was a CXXRecordDecl"? This would mean I
> should put the [dcl.typedef] logic back where it was before and handle
> this separately. I think you're right.
>

I meant what I said: we only want to merge attributes if the old
declaration was also a typedef (that is, the redeclaration chain of
typedefs has its own set of attributes that is independent of the
attributes on the redeclaration chain for the record, and we shouldn't
merge between them).

In fact, I probably need to be more explicit about this in general. In
> particular, we need to handle cases like:
>
>     typedef struct __attribute__((...)) X {
>       ...
>     } X __attribute((...));
>
> I guess in this case we should go ahead and do the merge. The case where
> we should skip the merge is only the special case where there are no
> attributes on the struct, as they're all described on the typedef. Make
> sense?


I think the first set of attributes should be applied to the RecordDecl and
the second set should be applied to the TypedefDecl. I don't think any
merging should occur in this case. We should only merge when we have a
redeclaration, and the typedef declaration is not a redeclaration of the
struct declaration.


> > Please also add to your testcase:
> >
> > struct TDS tds2; // no warning, attribute only applies to the typedef.
> >
> > ... and for good measure:
> >
> > typedef struct S { char c; } S __attribute__((aligned(8)));
> > S a;
> > struct S b;
> > static_assert(alignof(a) == 8, "");
> > static_assert(alignof(b) == 1, "");
>
> Will do.
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131007/cb67e0e8/attachment.html>


More information about the cfe-commits mailing list