On Wed, 11 Sep 2024, Patrick Palka wrote:
> On Wed, 4 Sep 2024, Marek Polacek wrote:
>
> > On Wed, Sep 04, 2024 at 10:58:25AM -0400, Jason Merrill wrote:
> > > On 9/3/24 6:12 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
> > >
> > > The change to return bool seems like unrelated cleanup; please push that
> > > separately on trunk only.
> >
> > Done.
> >
> > > > + /* We can also have:
> > > > +
> > > > + template <template <typename T, typename T::type TT>
> > > > typename X>
> > > > + void func() {}
> > > > + template <typename U, int I>
> > > > + struct Y {};
> > > > + void g() { func<Y>(); }
> > > > +
> > > > + where we are not in a template, but the type of PARM is
> > > > T::type
> > > > + and dependent_type_p doesn't want to see a
> > > > TEMPLATE_TYPE_PARM
> > > > + outside a template. */
... so the patch LGTM, except I'd prefer to not have this comment
containing an embedded specific testcase. IMHO it's "understood" that
processing_template_decl needs to be set when substituting using an
incomplete set of arguments since in that case the result must be
templated.
> > > > + ++processing_template_decl;
> > > > tree t = tsubst (TREE_TYPE (parm), outer_args, complain,
> > > > in_decl);
> > > > + --processing_template_decl;
> > > > if (!uses_template_parms (t)
> > > > && !same_type_p (t, TREE_TYPE (arg)))
> > >
> > > This looks like the pattern Patrick just removed from
> > > type_unification_real
> > > for PR101463. Do we want to make the same change here?
>
> The pattern does seem similar, but I can't see the benefit of making the
> same change here. In type_unification_real the change made dependent vs
> non-dependent deduction more uniform by removing the dependence tests.
>
> But nothing can be made more uniform here AFAICT. At best we can use
> find_template_parameters to see if 'parm' depends on outer template
> parameters and avoid the substitution if so. But both uses_template_parms
> tests need to remain, I think. Even if 'parm' doesn't depend on outer
> template parameters, it seems we still want to succeed if it's overall
> dependent as in the testcase from the PR. Likewise if 'arg' is overall
> dependent and 'parm' isn't.
>
> >
> > Interesting. Sorry, this may be silly, but I'm not sure I can do that
> > here: find_template_parameters wants "the template parameters in scope"
> > but I don't think I have that here.
>
> You could probably pass the DECL_TEMPLATE_PARMS of parm_tmpl or arg_tmpl
> of its caller.
>
