https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109381
Bug ID: 109381
Summary: Ambiguous member lookup with this-> accepted when it
should be rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/ex97db8cT
template<class T>
struct B {
int f() { return 1; }
};
struct C {
int f() { return 2; }
};
template<class T>
struct D : B<T>, C {
int test() {
return this->f(); // GCC calls C::f; Clang and MSVC reject
}
};
int main() {
D<int> d;
return d.test();
}
This can't possibly be unreported yet, but a quick search failed to find any
bug filed on the subject. Sorry if this is a duplicate.
GCC correctly thinks that `return f();` should call `C::f` because `B<T>::f` is
not considered because `B<T>` is a dependent base class and we didn't say
`this->`.
But, GCC wrongly thinks that `return this->f();` should ALSO call `C::f`. Clang
and MSVC agree that it should be ambiguous, because now it IS looked up in both
phase 1 and phase 2, and an `f` is found in both base classes, so the lookup
should be considered ambiguous.
According to Godbolt, the issue was introduced somewhere between GCC 7.5 (OK)
and GCC 8.1 (buggy).
