https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118698
--- Comment #15 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #12)
> Substituting <T,foo> into <decltype([]{},T> seems like a partial
> substitution to me. If the lambda itself had any template parameters of its
> own, or autos, we wouldn't want to reduce their level, so it seems
> tf_partial should be set during normalization?
Hmm, perhaps, it certainly seems related to the use of tf_partial in
instantiate_template. But doing that brings back the tsubst_lambda_expr
EXTRA_ARGS problems.
I think part of the problem is that tf_partial has gotten overloaded. The
original meaning was "we only have arguments for some of the parms at this
level". The use in instantiate_template has broadened the meaning to
"substituting without changing the number of levels of parms". Which would
also apply in normalization.
But it's unclear to me why we would want EXTRA_ARGS in that broader sense; if
we have all the args, we're just substituting them, I'd expect that to work
fine with the "leave auto alone" meaning.
And the assumption in add_extra_args seems wrong for the original sense; in
general with tf_partial we would not have a full set of template arguments,
though we might have enough of them to do the substitution. And we should have
the right number of levels, which is the point of that change.
So I suspect we want to split the broader meaning out of tf_partial, so places
like instantiate_template and normalize_concept_definition can choose it
without also getting the tsubst_lambda_expr EXTRA_ARGS effect.
Or perhaps it's enough to generally stop giving auto a level, so tf_partial can
go back to just the old meaning?
Incidentally, perhaps lambda types shouldn't care about current_template_parms
anyway, since they get regenerated rather than instantiated.
