Is this a clang bug? "Foo::Foo::bar"


the following program compiles with clang r186311, and I'm not sure if this is a bug
or correct behavior:

struct Foo {
    void bar();

void Foo::Foo::Foo::Foo::Foo::Foo::bar()

According to §3.3.7p1 bullet 5 (basic.scope.class), the potential scope of a class
includes "the regions defined by its member definitions [...] including the member
function body and any portion of the declarator part of such definitions which follows
the declarator-id", and § (class.qual) states that "A class member can be
referred to using a qualified-id at any point in its potential scope" while "the name
[specified after the nested-name-specifier] shall represent one or more members of
that class or of one of its base classes."

However in the code above the member function "bar" is referred to using a qualified-id
in its declarator-id, which is not part of the class' potential scope, and "Foo" isn't
a base class of itself, so this shouldn't be allowed.

Still, I'm not sure if I got all the subtleties of C++'s name lookup rules right, so
I'd like to make sure if this is a bug in clang or merely the somewhat amusing result
of the way names in C++ can be specified.

With many thanks in advance,

This is “injected-class-name”, see C++ standard (clause 9p2):

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.


That’s a bug:

The standard wording used to be ambiguous here, the resolution chosen by the committee didn’t match clang’s interpretation of the ambiguity, and no-one has gotten around to fixing it yet. Patches would be welcome :wink:


I tried to understand the PR15243 and I read the core issue 1310* but the examples given in both the ticket and the description with resolution 1310 focus on the lookup of a class constructor and not a member function, like the example given by Jonathan. How is it applicable here, it seems to me that there is no ambiguity about the fact that "Foo" cannot be the constructor in "Foo::Foo::bar"?



*C++ Standard Core Language Defect Reports and Accepted Issues

FYI, I submitted such issue some time ago:

It has been rejected as invalid at that time.

FYI, I submitted such issue some time ago:

It has been rejected as invalid at that time.

Oh, my bad, I should have looked at the example in this mail thread more closely. PR14100 is invalid, and the original code in this thread is valid.

You’re right, in this case, Foo::Foo::bar is valid. But it’s not a question of ambiguity – per DR1310, Foo::Foo names the constructor in all cases except:

  • before “::”,
  • after “struct”, “class” or “union”, or
  • in a class definition’s base specifier list
    … even if that makes the program ill-formed. This is the part that Clang doesn’t implement correctly (and is the subject of PR15243).