http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-09-21
23:56:25 UTC ---
(In reply to comment #6)
> Thanks, Manu. Most of the PRs mentioned on that page are FIXED, and I don't
PR 35441 is still broken. In any case, most of the fixes just gave up on
printing a reconstructed expression, and they print something else, for example
'({...})'.
> i.e. I'd rather see:
>
> no match for operator== with operands X& and Y&
>
> than:
>
> no match for operator== in 'foo == bar'
>
> because whether a suitable operator exists is a property of the variables'
> types, not their names.
>
> That might also be easier to implement, since the compiler knows the types.
I agree that this would be an improvement, even without clang's selective
typedef unwrapping. But I have some doubts such a patch will be accepted. I was
told in a couple of occasions that I cannot just remove the expression from the
diagnostic and rely on the user to look up the source code location.
