[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