[LLVMbugs] [Bug 9359] New: Clang thinks unambiguous member lookup is ambiguous (when dependent type is involved)

[bugzilla-daemon at llvm.org]

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

           Summary: Clang thinks unambiguous member lookup is ambiguous
                    (when dependent type is involved)
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhanyong.wan at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Build clang using configure + make.

$ cat t.cpp
namespace PR5820 {
struct Base {};
struct D1 : public Base {};
struct D2 : public Base {};

struct Derived : public D1, public D2 {
  void Inner() {
  }
};
}

template<typename T>
struct BaseT {
  int Member;
};

template<typename T> struct Derived1T : BaseT<T> { };
template<typename T> struct Derived2T : BaseT<T> { };

template<typename T>
struct DerivedT : public Derived1T<T>, public Derived2T<T> {
  void Inner();
};

template<typename T>
void Test(DerivedT<T> d) {
  d.template Derived2T<T>::Member = 17;
}

template void Test(DerivedT<int>);


$ Debug+Asserts/bin/clang -cc1 -fsyntax-only t.cpp
t.cpp:27:28: error: non-static member 'Member' found in multiple base-class
subobjects of type 'BaseT<int>':
    struct DerivedT<int> -> Derived1T<int> -> BaseT<int>
    struct DerivedT<int> -> Derived2T<int> -> BaseT<int>
  d.template Derived2T<T>::Member = 17;
                           ^
t.cpp:30:15: note: in instantiation of function template specialization
'Test<int>' requested here
template void Test(DerivedT<int>);
              ^
t.cpp:14:7: note: member found by ambiguous name lookup
  int Member;
      ^
1 error generated.

Note that this bug is strange in that it's sensitive to the seemingly unrelated
code in the input file (e.g. the code in namespace PR5820).  I even found that
it's sensitive to comments.

>From this, I suspect some kind of memory corruption.  Unfortunately, running it
under valgrind doesn't reveal much: valgrind complains about some conditional
jump depending on uninitialized values when comparing a default-initialized
SourceLocation (with ID == 0) with another SourceLocation, but I believe the
ctor of SourceLocation has properly initialized the ID field in this case, so
it looks like a valgrind false positive to me.

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