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

[Jason Merrill]

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