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
