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

Argiris Kirtzidis akyrtzi at gmail.com
Sat Aug 23 03:01:34 PDT 2008


Eli Friedman wrote:
> On Fri, Aug 22, 2008 at 8:16 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
>   
>> But exactly which parts of the statement should we examine to determine the
>> validity of a declaration.. this is left undefined.
>>     
>
> 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.

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.

Another one:

T(x) = 1, ++x;

Again, if we examine "++x" we will conclude that this is an expression. 
Now both GCC and MSVC only take into account "T(x) = 1" and consider the 
above example as declaration; GCC is more consistent here.

In general, one might say that it's a bit more consistent to treat 
statements as declarations by the first declarator:

T x, ++x;   // this is malformed declaration
T(x), ++x; // so is this

What do you think about comma-separated declarators vs. comma-separated 
expressions ?

>   
>> Here's an example:
>>
>> FuncType(a)(x,y)->z = 0;
>>
>> GCC will disambiguate it as a declaration and emit errors, Clang will
>> disambiguate it as an expression instead.
>>     
>
> What does the complete testcase look like?  Something like the following?
>
> struct S {int z;};
> typedef S* (*FuncType)(int,int);
> int x,y;
> S* a() {
>   FuncType(a)(x,y)->z = 0;
>   return 0;
> }
>
> I think that's pretty clearly an expression; there isn't any
> reasonable way to parse the -> operator as part of a declaration.  The
> Comeau compiler seems to agree, and accepts the given testcase.  This
> appears to be a bug in gcc; they'd probably appreciate it if you filed
> it.
>   

Ok, will do.

> I'll try to take a look at the patch sometime over the weekend.
>   

Thanks!


-Argiris



More information about the cfe-dev mailing list