[cfe-dev] [PATCH] C++ decl/expr ambiguity resolution

[Eli Friedman]

On Sun, Aug 24, 2008 at 8:14 AM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
>> +  if (Tok.is(tok::identifier)) {
>> +    // declarator-id
>> +    ConsumeToken();
>>
>> Don't you need some sort of check to see whether this is a type?
>>
>
> It doesn't matter whether it is a type or not. If it is a valid declaration,
> it shadows the type-name. If the type is in the same scope it may
> erroneously redeclare it but disambiguation doesn't take scope information
> into account.
>
> <sarcasm> I love that we are debating whether something is a declaration or
> an expression, the C++ grammar is so beautiful! </sarcasm>

Ah, oops.  Horrible stuff.

>> +Parser::TentativeParsingResult
>> +Parser::TryParseParameterDeclarationClause(SourceLocation LParenLoc) {
>> +  TentativeParsingResult TPR = TryParseDeclarationSpecifier();
>> +
>> +  if (TPR != TPR_false) {
>>
>> What the heck is this if statement supposed to be testing for?  Cases
>> like empty parameter declarations?  This whole area looks rather
>> strange.  I haven't worked out whether this has any visible effects,
>> but it seems like it would be a lot clearer to explicitly check for
>> the cases where TryParseDeclarationSpecifier returns false, but there
>> is in fact a valid parameter list (the only cases I can think of are
>> an empty parameter list and a list with only "...").
>>
>
> I've improved the readability of this function.

Definitely more readable; although, how is it supposed to deal with an
empty parameter declaration clause?

-Eli