On Mon, Apr 15, 2019 at 1:08 PM Paolo Carlini <paolo.carl...@oracle.com> wrote:
>
> Hi,
>
> On 12/04/19 20:29, Jason Merrill wrote:
> > On 4/11/19 11:20 AM, Paolo Carlini wrote:
> >> Hi,
> >>
> >> over the last few days I spent some time on this regression, which at
> >> first seemed just a minor error-recovery issue, but then I noticed
> >> that very slightly tweeking the original testcase uncovered a pretty
> >> serious ICE on valid:
> >>
> >> template<typename SX, typename ...XE> void
> >> fk (XE..., int/*SW*/);
> >>
> >> void
> >> w9 (void)
> >> {
> >> fk<int> (0);
> >> }
> >>
> >> The regression has to do with the changes committed by Jason for
> >> c++/86932, in particular with the condition in coerce_template_parms:
> >>
> >> if (template_parameter_pack_p (TREE_VALUE (parm))
> >> && (arg || !(complain & tf_partial))
> >> && !(arg && ARGUMENT_PACK_P (arg)))
> >>
> >> which has the additional (arg || !complain & tf_partial)) false for
> >> the present testcase, thus the null arg is not changed into an empty
> >> pack, thus later instantiate_template calls check_instantiated_args
> >> which finds it still null and crashes. Now, likely some additional
> >> analysis is in order, but for sure there is an important difference
> >> between the testcase which came with c++/86932 and the above:
> >> non-type vs type template parameter pack. It seems to me that the
> >> kind of problem fixed in c++/86932 cannot occur with type packs,
> >> because it boils down to a reference to a previous parm (full
> >> disclosure: the comments and logic in fixed_parameter_pack_p helped
> >> me a lot here). Thus I had the idea of simply restricting the scope
> >> of the new condition above by adding an || TREE_CODE (TREE_VALUE
> >> (parm)) == TYPE_DECL, which definitely leads to a clean testsuite and
> >> a proper behavior on the new testcases, AFAICS. I'm attaching what I
> >> tested on x86_64-linux.
> >
> > I think the important property here is that it's non-terminal, not
> > that it's a type pack. We can't deduce anything for a non-terminal
> > pack, so we should go ahead and make an empty pack.
>
> I see.
>
> Then what about something bolder, like the below? Instead of fiddling
> with the details of coerce_template_parms - how it handles the explicit
> arguments - in fn_type_unification we deal with both parameter_pack ==
> true and false in the same way when targ == NULL_TREE, thus we set
> incomplete. Then, for the new testcases, since incomplete is true, there
> is no jump to the deduced label and type_unification_real takes care of
> making the empty pack - the same happens already when there are no
> explicit arguments. Tested x86_64-linux. I also checked quite a few
> other variants of the tests but nothing new, nothing interesting, showed
> up...
OK.
Jason
