On Thu, 22 Mar 2012, Paolo Carlini wrote:
Hi,
On 03/22/2012 05:25 AM, Gabriel Dos Reis wrote:
On Wed, Mar 21, 2012 at 7:22 PM, Paolo Carlini<paolo.carl...@oracle.com>
wrote:
Hi,
this diagnostic issue is about not even trying to print expressions in
error
messages involving operators, and print operand types instead. Just as an
example, for:
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
we currently print:
error: no match for ‘operator=’ in ‘*(x + 4u) = 0’
which the patch changes to:
error: no match for ‘operator=’ (operand types are ‘X’ and ‘int’)
Or, for the existing other/error10.C, from:
error: no match for ‘operator-’ in ‘-(*& a)’
to
error: no match for ‘operator-’ (operand type is ‘A<0>’)
Usually these things appear in much less simpler expressions, possibly
involving
the same symbol but withe different meanings. There out be the a
way to give an indication of which symbol the diagnostic is about.
Withe the (imperfect) approach of printing expressions, at least some
indication
is given on the expression involved. Just printing the types with no
indication
of what expression is causing trouble is more head-scratching.
Yes, you are right. Yesterday I had another look to the audit trail and
thought, mistakenly, that people had a consensus about printing the types (by
the way we are dealing also with much worse cases, like the one in Comment #0
there). Thus I don't think for the time being I can do much here, maybe the
PR could be even closes as duplicate of the one about missing caret.
I haven't followed the whole diagnostic discussion, but what about
printing both the reconstructed expression and the types?
--
Marc Glisse
