[PATCH] PR c++/21930: Conversions in diagnostics

[Gabriel Dos Reis]

Roger Sayle <roger@eyesopen.com> writes:

| The following patch fixes PR c++/21930 which is a long standing
| problem with handling conversions in C++ error messages that was made
| more visible by my recent patch to introduce a UNARY_PLUS_EXPR tree
| code.
| 
| It turns out that prior to the new tree code for unary plus, the g++
| front-end already had "ambiguity" problems with it's misuse of
| CONVERT_EXPR, as witnessed by the code in dump_expr and the error
| messages generated for the example in the PR.  The overloading of
| CONVERT_EXPR meant that sometimes it represented a conversion/cast
| and sometimes a unary plus.  The code in dump_expr assumed the
| later, which further exposed/empahasized this issue when I moved
| this unary plus handling to it's own tree code.
| 
| The patch below corrects this by treating CONVERT_EXPR identically
| to NOP_EXPR, and removing the vestiages of handling unary plus as
| a cast for void types.  For the code in the attached testcase, the
| error message now reads:
| 
| testc.C: In function 'void foo(const A<N>&) [with int N = 0]':
| testc.C:13:   instantiated from here
| testc.C:9: error: no match for 'operator-' in '-((const A<0>&)((const A<0>*)a))'

It is an improvement, but it is awfull :-)
I'll follow up with a patch that reduces the noise.  
It there a way to tell from an CONVERT_EXPR whether it is explicit or
front-end generated?

| which is an improvement upon both current mainline and the erroneous
| message we generated with 4.0 and earlier (see the PR for details).
| 
| 
| The following patch has been tested on i686-pc-linux-gnu with a full
| "make bootstrap", all default languages, and regression tested with
| a top-level "make -k check" with no new failures.
| 
| Ok for mainline?

Yes.

[...]

| template<int N>
| void foo(const A<N> &a)
| { -A<N>(a); } // { dg-error "\\(\\(const A<0>\\*\\)a\\)" "" }

I think, you should just test for "-"...

-- Gaby