[Bug c++/17542] Visibility attribute ignored when it precedes class head

[austern at apple dot com]

------- Additional Comments From austern at apple dot com  2004-10-01 23:22 -------
Actually, this is almost straightforward.  It has nothing to do with the visibility attribute: it has to do 
with attributes and C++ classes in general.  Looking at cp_parser_class, and especially at 
cp_parser_class_head, attributes can appear in one of two places.  The parser will recognize either
 struct __attribute__((visibility("hidden"))) foo { virtual ~foo(); };
or
  struct foo { virtual ~foo(); } __attribute__((visibility("hidden")));

But, as the code and the comments both make quite clear, the syntax we're recognizing does not 
include an attribute list before the class-key.  

So then how come the __atrtribute__ is being swallowed and ignored?  Answer: what we've got here is a 
simple-declaration with two decl-specifiers, an attribute list and a class definition, and no declarators.  
The attribute list applies to a declarator, which in this case is missing.  We could instead have written:
  __attribute__((visibility("hidden"))) struct foo { virtual ~foo() { } } x;
In this case we can see that the attribute isn't being ignored; it just applies to x, not to foo.

I hesitate to call this "behaves correctly", since this behavior is unexpected, hard to understand, and 
leads to the user silently not getting what they expected.  I'm afraid that with visibility, in particular, it'll 
lead to problems because users will want to hide this attribute list behind macros that expand to 
different things on different platforms.  But I'm also not completely sure what the best thing to do is.  
Here are my two two choices:
 1. Special-case this construct.  If a simple-declaration consists of a class definition with no declarator, 
then any attributes preceding the class head get applied to the class.
 2. If cp_parser_simple_declaration collects attributes in  cp_parser_decl_specifier_seq and it's throwing 
them away because there's no declarator to apply them to, then warn the user and suggest a better 
place to put the attribute list.

Option 1 is admittedly a hack, but that doesn't necessarily mean it's a bad idea.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17542