[LLVMbugs] [Bug 12437] New: Failure to reject ambiguous function call

[bugzilla-daemon at llvm.org]

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

             Bug #: 12437
           Summary: Failure to reject ambiguous function call
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dibeas at ieee.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to 10.2p2:

The following steps define the result of name lookup in a class scope, C.
First, every declaration for the name in the class and in each of its base
class sub-objects is considered. A member name f in one sub-object B hides a
member name f in a sub-object A if A is a base class sub-object of B. Any
declarations that are so hidden are eliminated from consideration. Each of
these declarations that was introduced by a using-declaration is considered to
be from each sub-object of C that is of the type containing the declaration
designated by the using-declaration.

**If the resulting set of declarations are not all from sub-objects of the same
type, or the set has a nonstatic member and includes members from distinct
sub-objects, there is an ambiguity and the program is ill-formed. Otherwise
that set is the result of the lookup.**

With this test case:

struct A {
    void f(int x) {}
};
struct B {
    template<typename T> void f(T x) {}
};
struct C : public A, public B {};
int main() {
   C().f<int>();
}

I believe that the call C().f<int>() is ambiguous (A::f/B::f) but clang++ 3.0
compiles with no diagnostics. The same code is rejected by g++, comeau and
VS2010.

-- 
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.