[cfe-dev] error: use of overloaded operator '==' is ambiguous

[John McCall]

On Jul 29, 2010, at 6:03 PM, Shawn Erickson wrote:
> Sorry for the longish code example attached to this email but I am
> trying to understand if clang is being overly pedantic in this
> situation. Also please let me know if I should just file defects
> instead of posting to this mailing list (unsure if this is a clang
> problem or not).

Filing bugs is generally nicer.

> It seems like clang should be ignoring the private bool operators when
> searching for a candidate.

Access doesn't affect visibility in C++:  first you decide which operator you want,
then you decide whether you can access it.

> I assume the built-in ones would be
> ignored/not listed if the only direct candidate was int32_t.

If by 'direct candidate' you mean a member function candidate, you don't
consider member operators unless the left operand is of class type.  In this
case, Status::eNo has type ResultCodeConst, i.e. int64_t.  Neither ADL not
unqualified lookup find any user-defined operators, so the only possibilities
are the builtin candidates.

That said, I think the builtin candidate at (int64_t, int32_t) should be viable;
Doug, thoughts?

John.