Re: Attributes on structs

[Jason Merrill <jason at redhat dot com>]

Mark Mitchell wrote:
> That seems reasonable to me.  The transparent_union trick (copying the
> fields, along with making a new TYPE_MAIN_VARIANT) might work, but even
> there you have to worry about making sure you a different type_info
> object, how do you mangle the name, etc.  You're also likely to get
> messages like "can't convert X to X" because one of them has an attribute.

Yep.  That sort of thing seems reasonable for C, but not for C++, and so 
my inclination would be to disallow it for both.

Incidentally, while poking at this I noticed that build_duplicate_type 
has been broken since the gomp merge; it just returns the same type.  I 
would be inclined to just reject transparent_union as well, but it seems 
that existing practice is to write

typedef union { ... } U __attribute ((transparent_union));

which modifies the typedef copy of the union rather than the original 
type.  That is, if build_duplicate_type were doing its job.

I'm not sure what to do about this.  I'm reluctant to break the existing 
code that does this (such as the glibc stdlib.h).  Perhaps just passing 
the attribute through to the original type is appropriate for this case, 
but seems wrong for

union U2_ { ... };
typedef union U_ U2 __attribute ((transparent_union));

and I'm not sure how to distinguish the two in the compiler.  Of course, 
we could just pass it through in all cases and tell people who want to 
use both the original union and its transparent variant that they're 
crazy and need to write another union.

Note that when I fix build_duplicate_type to work properly, the C++ 
compiler rejects the first usage because U doesn't refer to the original 
type, so it isn't used for linkage.  Perhaps that's why 
build_duplicate_type got broken.

Jason