c++ - Injected class name compiler discrepancy

Question

Consider this code:

struct foo{};

int main() {
    foo::foo a;
}

I would expect this to be well-formed, declaring a variable of type foo by the rule in [class]/2 (N4140, emphasis mine):

A class-name is inserted into the scope in which it is declared immediately after the class-name is seen. The class-name is also inserted into the scope of the class itself; this is known as the injected-class-name. For purposes of access checking, the injected-class-name is treated as if it were a public member name.

clang 3.6.0 agrees with me, compiling the above code with no applicable warnings with -Wall -pedantic.

gcc 5.2.0 disagrees, providing the following error message:

main.cpp: In function 'int main()':
main.cpp:5:5: error: 'foo::foo' names the constructor, not the type
   foo::foo a;

The above holds no matter how deep the nesting of injected class names, e.g. foo::foo::foo::foo.

Is there a rule which forces that construct to be interpreted as a constructor in that context, or is this agcc bug? Or am I interpreting the standards quote incorrectly?

Answer 1

It appears that clang is wrong in this case. The relevant exception I was looking for is in [class.qual]/2:

2 In a lookup in which function names are not ignored and the nested-name-specifier nominates a class C:

• (2.1) if the name specified after the nested-name-specifier, when looked up in C, is the injected-class-name of C, or

• [...]

the name is instead considered to name the constructor of class C.

The standard has a near-equivalent (non-normative, obviously) example:

struct A { A(); };
struct B: public A { B(); };

A::A() { }
B::B() { }

B::A ba;// object of type A
A::A a;// error, A::A is not a type name
struct A::A a2;// object of type A

However, clang actually issues a correct diagnostic in this case:

error: qualified reference to 'A' is a constructor name rather than a type wherever a constructor can be declared

Perhaps clang interprets the line In a lookup in which function names are not ignored as In a lookup in which a constructor declaration is valid, but that doesn't seem to be a correct interpretation.

There is an existing bug for this in the clang bugzilla.