[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