[cfe-dev] ParseTag only called from ParseEnumSpecifier

[Doug Gregor]

On Thu, Sep 4, 2008 at 7:30 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Doug Gregor wrote:
>>
>> On Wed, Sep 3, 2008 at 2:36 PM, Ted Kremenek <kremenek at apple.com> wrote:
>>
>>>
>>> As a side note, my original interest in this code was to allow the
>>> parser+actions to be able to distinguish up front between enum/struct/
>>> union/class forward declarations and definitions.
>>>
>>
>> FWIW, this requires arbitrary lookahead in C++ (but not in C), since
>> we can't tell the difference between a class-specifier and an
>> elaborated-type-specifier until we've parsed through the
>> nested-name-specifier and hit the actual class identifier (or
>> template-id). Of course, one could apply Argiris' pre-parser idea to
>> do the disambiguation between these two nonterminals in advance.
>>
>
> In an attempt at parsing nested-name-specifiers, inside ParseClassSpecifier,
> the parser would parse the nested-name-specifier, get it resolved to a
> CXXScopeTy* by Sema, and pass this pointer to ActOnTag along with the other
> information (identifier etc.). That way there's no need for lookahead.

If I understood Ted correctly, what he's thinking of would require
lookahead... I'll elaborate below.

> On Wed, Sep 3, 2008 at 2:36 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
>> As a side note, my original interest in this code was to allow the
>> parser+actions to be able to distinguish up front between enum/struct/
>> union/class forward declarations and definitions.
>>
>
> Doesn't already the parser+actions distinguish them ? ActOnTag gets passed a
> TagKind which is one of TK_Definition/TK_Declaration/TK_Reference.

I *think* Ted meant that he wants to be able to know before actually
parsing the struct-or-union-specifier (in C) whether it's going to
declare, define, or reference a tag. This can be done with just a
little bit of lookahead. In the C++ world, this would mean knowing
whether we're parsing a class-specifier or an
elaborated-type-specifier, and allow us to have different Parse
functions for these two nonterminals (which are actually quite
different, despite the ambiguity), rather than combining them into a
single ParseClassSpecifier (which is really
ParseClassSpecifierOrNonEnumElaboratedTypeSpecifier!).

  - Doug