相同类型重定义的 Clang typedef（和别名）导致意外错误

Question

The code

template <typename T, typename Y>
class B;

template <typename T, typename Y>
class A {
public:
  typedef B<T, Y> handle;

  void func(B<T, Y> &arg);
};

template <typename T, typename Y>
class B {
public:    
  typedef B<T, Y> handle;

private:
  int i;

public:
  // friend void A<T,Y>::func(B<T, Y>& arg); //builds
  friend void A<T, Y>::func(handle &arg); // builds with alias in A *not* defined, otherwise fails.
};

template <typename T, typename Y> void A<T, Y>::func(B<T, Y> &arg) {
  arg.i = 9;
}

int main() {
    B<int, int> b;
    A<int, int> a;
    a.func(b); // error
}

The error

main.cpp:31:7: error: 'i' is a private member of 'B<int, int>'
  arg.i = 9;
      ^
main.cpp:38:5: note: in instantiation of member function 'A<int, int>::func' requested here
  a.func(b);
    ^
main.cpp:23:7: note: declared private here
  int i;
      ^
1 error generated.

The problem

I was trying to get my company's code to build under clang, and ran across this scenario. The code builds under GCC 5 - 8. I've tried to find a rule that describes this scenario, but have come up empty. The fix (or workaround) is obvious, but I'm seeking clarification of what is going on to better understand the scenario.

So both classes define the same typedef (also tried with aliases, same result) as the same type. If the typedef is used as the type for the friend declaration, it gives the error above, with one exception. When the typedef is not present in A but is in B. It will also build if you strip out the templates.

Thanks for any insights!

Answer 1

This is roughly CWG 1906 . Basically, clang implemented the actual wording in the standard - which didn't make much sense.

Basically, consider this example, courtesy of Richard Smith:

namespace A { 
  struct X { void f(int); }; 
} 
namespace B { 
  using type = int; 
  struct Y { 
    friend void A::X::f(type);
  }; 
} 

The standard's lookup order for type used to be A::X , B::Y , B , :: . Clang did A::X , A , :: , B::Y , B , :: . gcc did A::X , B::Y , A , :: .

Now, the standard's lookup order is the same as if we were in the context of Y :

for a friend declaration in a class Y , in a scope that would be searched for a name appearing within Y .

That is, B::Y , B , :: and we never consider A . In other words, for your original example, B::handle would be found (as desired), rather than A::handle .