http://llvm.org/bugs/show_bug.cgi?id=8263

           Summary: Incorrect constructor name resolution
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: [email protected]
        ReportedBy: [email protected]
                CC: [email protected], [email protected]


The following looks well-formed

struct A { 
  typedef A type;
};

// The following is SFINAE'ed out if T is A
template<typename T>
void f(typename T::A*);

// The following is not when T is A
template<typename T>
void f(typename T::type*);

int main() {
  f<A>(0);
}


Clang says

main1.cpp:14:3: error: call to 'f' is ambiguous
  f<A>(0);
  ^~~~
main1.cpp:7:6: note: candidate function [with T = A]
void f(typename T::A*);
     ^
main1.cpp:11:6: note: candidate function [with T = A]
void f(typename T::type*);
     ^

And the Standard says at [class.qual]p2

"In a lookup in which the constructor is an acceptable lookup result and the
nested-name-specifier nominates a class C [...]  if the name specified after the
nested-name-specifier, when looked up in C, is the injected-class-name of C
[...] the name is instead considered to name the constructor of class C.".

A constructor is an acceptable lookup result for a "typename ...", since
function names are not ignored in a typename-specifier during lookup (see the
clearifying note at p2). Clang restricts that replacement to situations where
constructors can be declared only, though. 

The above code is accepted by comeau online compiler. Usually I found GCC
rejects all the cases I expect it to for the constructor name replacement (i.e
it acts not like clang in this regard), but GCC also rejects the above code.
But that is because GCC ignores function names in a typename-specifier lookup,
not because it wouldn't do the constructor-name replacement in general.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs

Reply via email to