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]

Re: [SKETCH] Refactor implicit function template implementation and fix 58534, 58536, 58548, 58549 and 58637.


On 10/07/2013 05:14 AM, Adam Butcher wrote:
+		  /* Forbid ambiguous implicit pack expansions by only allowing
+		     a single generic type in such a parameter.

+		     XXX: Maybe allow if explicitly specified template
+		     XXX: 'typename...' account for all expansions?  Though this
+		     XXX: could be tricky or slow.

This seems wrong.  The standard says,

The invented type template-parameter is a parameter pack if the corresponding parameter-declaration de-
clares a function parameter pack (8.3.5).

So if we have a function parameter pack, any generic type parameters in the type are packs.

+	  /* If there is only one generic type in the parameter, tentatively
+	     assume that that it is a parameter pack.  If it turns out, after
+	     grokdeclarator, that the parameter does not contain a pack
+	     expansion, then reset it be a non-pack type.  */
+	  if (cp_num_implicit_template_type_parms == 1)
+	    TEMPLATE_PARM_PARAMETER_PACK
+	      (TEMPLATE_TYPE_PARM_INDEX
+		(cp_last_implicit_template_type_parm)) = true;

This will cause problems with type comparison, since TYPE_CANONICAL of the implicit parm doesn't have TEMPLATE_PARM_PARAMETER_PACK set. That's why I was talking about using tsubst to replace a non-pack with a pack.

+	parser->implicit_template_scope = class_scope;
+      else
+	parser->implicit_template_scope = fn_parms_scope;
+      current_binding_level = parser->implicit_template_scope->level_chain;

Why not make implicit_template_scope the actual template scope, rather than the function/class? It looks like all the users immediately take the level_chain.

+/* Nonzero if parsing a context where 'auto' in a parameter list should not
+   trigger an implicit template parameter.  Specifically, 'auto' should not
+   introduce a new template type parameter in explicit specializations, trailing
+   return types or exception specifiers.  */
+int cp_disable_auto_as_implicit_function_template_parm;

Can we put this in cp_parser, invert the sense of the flag, and only set it during cp_parser_parameter_declaration_clause?

Jason


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