rsmith added a comment. In D155387#4579866 <https://reviews.llvm.org/D155387#4579866>, @ilya-biryukov wrote:
> I believe this should compile as according to (over.match.oper)p4 > <https://eel.is/c++draft/over.match.funcs#over.match.oper-4>: > >> A non-template function or function template F named operator== is a rewrite >> target with first operand o unless **a search for the name operator!= in the >> scope S** from the instantiation context of the operator expression finds a >> function … > > And 'search' is defined without any checks for ambiguous bases in > (basic.lookup.general)p3 <https://eel.is/c++draft/basic.lookup#general-3> > >> A single search in a scope S for a name N from a program point P finds all >> declarations that precede P to which any name that is the same as N >> ([basic.pre]) is bound in S. If any such declaration is a using-declarator >> whose terminal name ([expr.prim.id.unqual]) is not dependent >> ([temp.dep.type]), it is replaced by the declarations named by the >> using-declarator ([namespace.udecl]). > > Clang does a full lookup instead, therefore exposing the errors that it > should not diagnose. A search of a class scope is ill-formed if it finds an ambiguous result, see http://eel.is/c++draft/basic.lookup#class.member.lookup-6.sentence-2 -- that's the rule that we're now enforcing more broadly, and it applies to all searches of class scopes. So I think Clang is correct to reject your testcase, even though the ambiguity seems much less relevant in this case and the rejection is surprising. The fix / workaround is to add `using X::operator!=; using Y::operator!=;` to the derived class. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D155387/new/ https://reviews.llvm.org/D155387 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
