[cfe-dev] ParseClassSpecifier: can "unions" inherit?

steve naroff snaroff at apple.com
Thu Sep 4 10:32:39 PDT 2008


On Sep 4, 2008, at 11:06 PM, Argiris Kirtzidis wrote:

> steve naroff wrote:
>> On Sep 4, 2008, at 12:19 PM, Nico Weber wrote:
>>
>>
>>> Hi,
>>>
>>> On 04.09.2008, at 18:01, Ted Kremenek wrote:
>>>
>>>
>>>> I just noticed the following code fragment in ParseClassSpecifier:
>>>>
>>>> // Parse the tag portion of this.
>>>> DeclTy *TagDecl = Actions.ActOnTag(CurScope, TagType, TK, StartLoc,
>>>> Name,
>>>>                                    NameLoc, Attr);
>>>>
>>>> // Parse the optional base clause (C++ only).
>>>> if (getLang().CPlusPlus && Tok.is(tok::colon)) {
>>>>   ParseBaseClause(TagDecl);
>>>> }
>>>>
>>>> It appears from the code that the 'if' branch can be taken even  
>>>> if  the
>>>> tag decl is a union.  Is this valid in the C++ grammar?  That is,  
>>>> can
>>>> there be a "base clause" for unions in C++, and if so, what does  
>>>> that
>>>> mean?
>>>>
>>> it seems not to be allowed -- at least both gcc and clang reject it.
>>> Clang does it in ActOnBaseSpecifier in Sema:
>>>
>>>  // C++ [class.union]p1:
>>>  //   A union shall not be used as a base class.
>>>  if (BaseType->isUnionType()) {
>>>    Diag(BaseLoc, diag::err_union_as_base_class, SpecifierRange);
>>>    return;
>>>  }
>>>
>>>
>>
>> That's odd - it seems like this should be diagnosed by the parser.   
>> Since I'm not very familiar with all the "challenges" of  
>> implementing C ++:-), I'll understand if this isn't convenient.
>>
>
> Doug can probably explain it better, but it's not the C++ grammar  
> that disallows union inheriting, it's the "semantic rules".
> Also, in general, as suggested by Chris here:
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-June/002004.html
> it's better for the Parser to be as "relaxed" as possible and defer  
> error checking to Sema (where appropriate).
>

Thanks for the reference. Chris did a great job explaining the  
tradeoffs.

The unfortunate side-effect of doing everything in Sema is it  
complicates writing new "Action" modules. This isn't really a big  
deal, since writing a new Action module is non-trivial anyway (for C).  
For example, ActOnDeclarator() does a ton of work to validate what the  
user actually typed.

At present, it appears we've standardized on supporting multiple  
applications using clangs AST's. As long as this continues to work  
well, the issue of writing other Action modules is probably academic.

snaroff

>
> -Argiris




More information about the cfe-dev mailing list