[Bug c++/49152] Unhelpful diagnostic for iterator dereference

["manu at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.