This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

don't issue duplicate template errors


On Jan 31, 2005, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> Alexandre, this patch [for bug 18757] was clearly incorrect.  The
> whole reason to create CPP_TEMPLATE_ID tokens is to avoid re-parsing
> the same token sequence in the case that an error occurred.  Please
> revert this patch ASAP.

> Feel free to assign the original bug which your patch fixed to me.

Doh!  I've had an alternate patch for this bug ever since I learned
the original patch had caused so much trouble, and was wondering why
nobody bothered to review it.  I just found out the reason: I hadn't
got 'round to actually posting it :-/

Here it is.  Mark, can you tell whether the assumption after the `???'
comment is correct?  If so, ok to install?

I'm yet to verify whether it will require tweaks in testcases; it's
quite possible, and this may be the reason why I didn't submit it.

Sorry about the breakage.

Index: gcc/cp/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	PR c++/18757
	PR c++/19366
	PR c++/19499
	* parser.c (cp_parser_template_id): Revert 2004-12-09's patch.
	Issue an error when creating the template id.
	* pt.c (fn_type_unification): Return early if the explicit
	template arg list is an error_mark_node.

Index: gcc/cp/parser.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v
retrieving revision 1.304
diff -u -p -r1.304 parser.c
--- gcc/cp/parser.c 29 Jan 2005 02:07:05 -0000 1.304
+++ gcc/cp/parser.c 31 Jan 2005 18:51:01 -0000
@@ -8442,7 +8442,7 @@ cp_parser_template_id (cp_parser *parser
      error messages about problems during instantiation of the
      template.  Do so only if parsing succeeded, otherwise we may
      silently accept template arguments with syntax errors.  */
-  if (start_of_id && !cp_parser_error_occurred (parser))
+  if (start_of_id)
     {
       cp_token *token = cp_lexer_token_at (parser->lexer, start_of_id);
       
@@ -8453,6 +8453,13 @@ cp_parser_template_id (cp_parser *parser
       
       /* Purge all subsequent tokens.  */
       cp_lexer_purge_tokens_after (parser->lexer, start_of_id);
+
+      /* ??? Can we actually assume that, if template_id ==
+	 error_mark_node, we will have issued a diagnostic to the
+	 user, as opposed to simply marking the tentative parse as
+	 failed?  */
+      if (cp_parser_error_occurred (parser) && template_id != error_mark_node)
+	error ("parse error in template argument list");
     }
 
   pop_deferring_access_checks ();
Index: gcc/cp/pt.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/pt.c,v
retrieving revision 1.970
diff -u -p -r1.970 pt.c
--- gcc/cp/pt.c 29 Jan 2005 00:47:46 -0000 1.970
+++ gcc/cp/pt.c 31 Jan 2005 18:51:09 -0000
@@ -9123,6 +9123,9 @@ fn_type_unification (tree fn, 
       tree converted_args;
       bool incomplete;
 
+      if (explicit_targs == error_mark_node)
+	return 1;
+
       converted_args
 	= (coerce_template_parms (DECL_INNERMOST_TEMPLATE_PARMS (fn), 
 				  explicit_targs, NULL_TREE, tf_none, 
-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]