[RFH / Patch] c++/52432

[Paolo Carlini]

Hi,

today Jon filed this PR about 'reporting routines re-entered' with 
-fdump-tree-gimple and first I tried to figure where we are trying to 
produce an error from inside the diagnostic code itself.

Turns out that tsubst_copy_and_build, case CALL_EXPR, calls 
unqualified_name_lookup_error unconditionally, that is without checking 
that complain includes tf_error. This certainly cannot be Ok vs 
dump_template_bindings which just passes tf_none.

Thus I added the check (see attached), and the interesting story begins 
here ;) What happens is that c++/52432 is indeed fixed and the testsuite 
is mostly Ok, but decltype32.C regresses, in that, instead of the 
relatively concise message saying that "‘make_array’ was not declared in 
this scope" we have a recursion of error messages, all identical, saying 
that "‘make_array’ was not declared in this scope, and no declarations 
were found by argument-dependent lookup at the point of instantiation". 
In other terms, we get to the above mentioned case of 
tsubst_copy_and_build a first time and we don't call 
unqualified_name_lookup_error because complain is tf_none, thus the 
error message currently produced in mainline is not produced, then we 
get there again multiple, multiple times producing the permerror right 
above it.

Looks like the issue has to do with the mechanism we have in 
add_template_candidate_real which checks for actual errors produced via 
the errorcount global in order to improve the diagnostics, but I'm not 
sure yet about the details of that.

Thus I'm looking for some help about the best way to proceed. First, do 
we agree that tsubst_copy_and_build should never call 
unqualified_name_lookup_error unconditionally? Any tips about decltype32.C?

I'm still looking into the issue, anyway.

Thanks!
Paolo.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20120229/42a907e4/attachment.ksh>