[cfe-commits] Note and FixIt for additional case of vexing parse

Nikola Smiljanic popizdeh at gmail.com
Thu Jul 26 15:12:26 PDT 2012


> Please move this into an "if (FTI.isAmbiguous)" check. We don't want to pay
> for this when building every function type. Also, if you can factor this out
> to a separate function, that would help avoid disrupting the flow of this
> function.

In that case I could add a function IsPointerDeclarator (probably
should name it differently?) to Declarator and call both it and
IsFunctionDeclarator inside the "if (FTI.isAmbiguous)". The code would
look something like this:

// avoid other costly checks if possible
if (FTI.isAmbiguous) {
    if (other conditions including IsFunctionDeclarator and IsPointerDeclarator)
}

> We should also be checking (RT->isRecordType() || FTI.NumArgs <= 1) here.

I still don't get this part, but it might be because we don't
understand each other about the "return type a reference" stuff. See
the next part.

> I don't follow. If the return type is a reference, then it's not a class type.

I'm not very good at standardese so my terminology might be off. When
I say a reference, I mean something like this:

int &foo();
MyClass &bar();

Return type is a reference to some other type that might be a class
type (class MyClass {};) or a built-in type. I just don't see how
return type being a class type changes anything? If it's a reference
then it must be initialized, and it can be initialized with only one
value (just like a pointer).

int x;
int y;
int &ref(x);

ref refers to x (alias), and there is no way to initialize it with
less than one or more than one parameter. Both "int &ref()" and "int
&ref(x, y)" would indicate that this is a function declaration (where
x and y would have to be some types), there can't be any ambiguity
here???

I hope you understand what it is that I don't understand. Sorry for
being such a pain, and thanks for all the help!



More information about the cfe-commits mailing list