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

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-09-21 23:30:34 UTC ---
Thanks, Manu.  Most of the PRs mentioned on that page are FIXED, and I don't
see specific mention of outputting the types involved in the operation, just
better way of outputting the original source instead of reconstructing it.  In
many cases the types would be more useful than printing the original source
range.

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. It
doesn't (without a lot of work) know the character range from the original
source file that corresponds to the expression.

Another alternative would be to note when operator notation is used, so that
when *foo is transformed to a call to the member function foo.operator*()
internally, the diagnostic can know to reconstruct it to *foo not
foo.operator*() in diagnostics.
This might only be needed for operators, since I haven't encountered such
serious problems with reconstructing normal function calls such as bar(g), only
for operator notation.