[PATCH] D155387: [Clang] Fix member lookup so that we don't ignore ambiguous lookups in some cases

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 21 15:17:44 PDT 2023


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



More information about the cfe-commits mailing list