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. > Jon and Manuel checked clang and I checked what icc does: without the caret, > I don't think we can do *much* better here, but, wrt the audit trail I think printing part or all of the expression is better in absence of carets. We can improve on the pretty printing of expressions, for example. > discussion, I'm proposing printing the actual operand types between > parentheses - I got the general idea from icc - because we don't want to > confuse parameters and arguments. > > Tested x86_64-linux. > > Thanks, > Paolo. > > ///////////////////////// > > > >
