[cfe-dev] More Vexing Than the Most Vexing Parse; Clang Parser Bug?

[Johannes Schaub]

Am 11.07.2012 07:00, schrieb Richard Smith:
> On Tue, Jul 10, 2012 at 8:14 PM, John McCall
> <rjmccall at apple.com
> <mailto:rjmccall at apple.com>> wrote:
>
>     On Jul 10, 2012, at 7:07 PM, Seth Cantrell wrote:
>      > I'm trying to figure out against whom to file a bug.
>      >
>      > This code is parsed differently between Clang, VC++, Comeau, and GCC.
>      >
>      > struct A {
>      >    A() {}
>      >    A(int) {}
>      > };
>      >
>      > struct B : A {
>      >    void init(int i);
>      > };
>      >
>      > void B::init(int i) {
>      >  {
>      >    A::A(i); // what is this supposed to parse as?
>      >  }
>      > }
>      >
>      > int main() {
>      >    B b;
>      >    b.init(2);
>      > }
>      >
>      > Clang and an earlier version of GCC parse it a variable
>     declaration, Comeau and current gcc parse it as an illegal
>     constructor call (but since it's illegal is that constructor really
>     "an acceptable lookup result" according to §3.4.3.1/2?
>     <http://3.4.3.1/2?>), and VC++ seems to parse it as constructing a
>     temporary (which it seems hard to fathom how because if A::A is a
>     constructor name then it's not legal to call and does not 'return' a
>     temporary object, but if A::A is a type name then this is a variable
>     declaration).
>
>     The standard doesn't precisely define "acceptable lookup result",
>     but I think (given the example in the immediate context of an
>     elaborated-type-specifier) that an acceptable lookup result is one
>     which is not ignored by the kind of lookup being performed.
>

One problem
> with the current statement of the rule is that we must perform two
> different kinds of lookup: we must look A::A up as a
> simple-type-specifier in case it's a decl-specifier, and we must look it
> up as a qualified-id in case there is no decl-specifier-seq.

Why do we must perform two different kinds of lookup? As far as I can 
see, "A::A" can never be a decl-specifier.

Only for the current approach of clang, I can imagine such a complication.

For the
> former lookup, a constructor is (presumably) not an acceptable lookup
> result, but core issue 147 strongly suggests that the intention was that
> the lookup should find the constructor anyway for that case.
>

Not only core issue 147, but the direct in-committee response does so :)

>     clang is just failing to apply the rule that this is really a
>     reference to the constructor.  In fact, I'm not sure we implement
>     that rule at all.
>
>
> We do: look for err_out_of_line_type_names_constructor. It seems that
> whoever implemented that interpreted "constructor is an acceptable
> lookup result" as meaning "appears somewhere a constructor could be
> declared". We reject this, for instance:
>
> struct S {}; S::S(i);
>

There has been a PR open for this. See 
http://llvm.org/bugs/show_bug.cgi?id=8263