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

[Chris Lattner]

On Aug 23, 2008, at 3:01 AM, Argiris Kirtzidis wrote:
>> Hmm... I see the following: "Note: To disambiguate, the whole
>> statement might have to be examined to determine if it is an
>> expression-statement or a declaration."  I think this is pretty  
>> clear;
>> if there were some allowable shortcuts, they would be documented in
>> the standard.
>>
>
> Yes but the "might have..." is pretty... ambiguous :)
> One might say,
> "by examining these parts of the statement I can conclude whether  
> it's a declaration or expression"
> another one might say
> "these parts are not enough, I'll continue to examine the rest of  
> the statement".
> The standard says "statement disambiguated as a declaration may be  
> an ill-formed declaration", so the first one can say "with these  
> parts of the statement I concluded it's a declaration, if the next  
> parts do not compile as a declaration then it's an ill-formed  
> declaration".
>
> If the standard said "the whole statement *should* be examined to  
> determine.." it would be more clear. But this is very subtle and I  
> may be wrong.

I agree with Eli.  The standard is very clear here, and it sounds like  
these are bugs in GCC.  Specifically, if a whole statement can be  
parsed as a declaration, it should be.  If the whole statement can't,  
and it is legal as an expression, then it must be parsed as a  
statement.  Rejecting a legal expression because it doesn't fit the  
declaration syntax would be a bug.

> The issue is mostly how to deal with comma separated declarators/ 
> expressions:
>
> int(x), ++x;
>
> if we examine "++x" we will conclude that this is an expression. If  
> we only examine "int(x)" we will regard this as declaration (note  
> that the C++ standard does not have such an example).
> GCC examines only the first declarator, while MSVC examines all of  
> them.
> Given that comma separated declarators are *much* more common than  
> comma separated expressions, and that a function-style cast followed  
> by a comma is mostly useless, I chose to go along with GCC and only  
> examine the first declarator.

I agree that this isn't a common case, but it would be very preferable  
for clang to get it right. :)

Another related but purely orthogonal issue is the efficiency  
concern.  It is preferable to avoid backtracking in obvious cases  
where we know that something is a statement.  For example, it is  
impossible for a declaration to start with the 'do' keyword, so if we  
see that, we can avoid the cost of starting/reverting backtracking.

-Chris