[C++ Patch] PR 51908

[Jason Merrill]

On 06/05/2013 09:07 AM, Paolo Carlini wrote:
> Hi,
>
> On 06/05/2013 02:53 PM, Jason Merrill wrote:
>> On 06/04/2013 08:34 PM, Paolo Carlini wrote:
>>>         /* After seeing a decl-specifier-seq, if the next token is not a
>>> -     "(", there is no possibility that the code is a valid
>>> +     "(" nor '...', there is no possibility that the code is a valid
>>>        expression.  Therefore, if parsing tentatively, we commit at
>>>        this point.  */
>>>
>>> clearly in the case at issue of decl-specifier-seq followed by ellipsis
>>> we may be parsing a perfectly valid declaration.
>>
>> Yes, but not an expression, which is why we are committing there: we
>> know it *has* to be a declaration.
> I see, I didn't notice the reference to *expressions* in the comment.
>>   The non-variadic case should hit that commit, so your change doesn't
>> seem to make the variadic case more consistent.
> But the non-variadic case does *not* hit the commit, because is handled
> above:
>
>    /* If the next token is a `)', `,', `=', `>', or `...', then there
>       is no declarator. However, when variadic templates are enabled,
>       there may be a declarator following `...'.  */
>    if (token->type == CPP_CLOSE_PAREN
>        || token->type == CPP_COMMA
>        || token->type == CPP_EQ
>        || token->type == CPP_GREATER)
>      {
>        declarator = NULL;
>        if (parenthesized_p)
>      *parenthesized_p = false;
>      }
>
> Thus it seems to me that the variadic case should also somehow not-hit
> the commit, do you agree?

Well, the comment here is correct: (Args... args) would also be 
well-formed.  But in the testcase there isn't a declarator, so the 
comment following the above, "Otherwise, there should be a declarator", 
is wrong.  I guess the above should also check for ... followed by one 
of those tokens.

In any case, the commit doesn't seem like the problem.  I'm not sure why 
it's in the else block rather than before the if.

Jason