diff mbox

[RFH,/] c++/52432

Message ID 4F4E6A4B.9080005@oracle.com
State New
Headers show

Commit Message

Paolo Carlini Feb. 29, 2012, 6:11 p.m. UTC 
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.

Comments

Jason Merrill March 1, 2012, 1:47 a.m. UTC | #1 
On 02/29/2012 01:11 PM, Paolo Carlini wrote:
> 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?

Yes.

> Any tips about decltype32.C?

The substitution failure should have removed the candidate from further 
consideration; sounds like something isn't propagating the failure back 
up (as I was talking about in my response to your 51214 patch).

Jason
Jason Merrill March 1, 2012, 1:51 a.m. UTC | #2 
On 02/29/2012 08:47 PM, Jason Merrill wrote:
> The substitution failure should have removed the candidate from further
> consideration; sounds like something isn't propagating the failure back
> up (as I was talking about in my response to your 51214 patch).

No, wait, now we're talking about the error messages explaining the 
substitution failure, right.  I can't think of a reason for that to show 
up more than once.

Jason
diff mbox

Patch

Index: pt.c
===================================================================
--- pt.c	(revision 184643)
+++ pt.c	(working copy)
@@ -13918,7 +13918,8 @@ 
 	      }
 	    if (TREE_CODE (function) == IDENTIFIER_NODE)
 	      {
-		unqualified_name_lookup_error (function);
+		if (complain & tf_error)
+		  unqualified_name_lookup_error (function);
 		release_tree_vector (call_args);
 		return error_mark_node;
 	      }