On Wed, 10 Apr 2024, Jason Merrill wrote:
> On 3/27/24 10:01, Patrick Palka wrote:
> > On Mon, 25 Mar 2024, Patrick Palka wrote:
> > > On Mon, 25 Mar 2024, Patrick Palka wrote:
> > > >
> > > > The below testcases use a lambda-expr as a template argument and they
> > > > all trip over the below
On 3/27/24 10:01, Patrick Palka wrote:
On Mon, 25 Mar 2024, Patrick Palka wrote:
On Mon, 25 Mar 2024, Patrick Palka wrote:
The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because
> > > + args = add_extra_args (LAMBDA_EXPR_EXTRA_ARGS (t), args, complain,
> > > in_decl);
> > > + if (processing_template_decl && !in_template_context)
> > > +{
> > > + /* Defer templated substitution into a lambda-expr
xpr used as a template argument. */
>
> And this comment is stale (an earlier version of the patch also deferred
> for dependent arguments even when current_template_parms is non-empty,
> which I backed out to make the fix as narrow as possible).
FWIW I also experimented with uncondi
t; + /* Defer templated substitution into a lambda-expr when arguments
> + are dependent or when we lost the necessary template context,
> + which may happen for a lambda-expr used as a template argument. */
And this comment is stale (an earlier version of the patch also de
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty, which causes
