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

[Eli Friedman]

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.

> -If GCC parses a statement without errors, Clang will parse it the same way.

That's always good :)

> -If GCC parses a statement and emits errors because it treats it as
> erroneous declaration, Clang may treat it as a correct expression instead.

We don't want to be accepting incorrect code, but it doesn't look like
that's the case here.

> 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.

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

-Eli