On Fri, 26 Jul 2024, Jakub Jelinek wrote:
> On Fri, Jul 26, 2024 at 09:49:27PM +0200, Jakub Jelinek wrote:
> > On Fri, Jul 26, 2024 at 08:43:44PM +0200, Jakub Jelinek wrote:
> > > Yeah, I saw ARGUMENT_PACK_SELECT being used, but didn't notice that
> > > important
> > > if (arg_pack && TREE_CODE (arg_pack) == ARGUMENT_PACK_SELECT)
> > > arg_pack = ARGUMENT_PACK_SELECT_FROM_PACK (arg_pack);
> > > part of tsubst_pack_expansion where it picks the pack from
> > > ARGUMENT_PACK_SELECT when needed.
> > >
> > > I also saw the iterative_hash_template_arg case and was afraid to modify
> > > it
> > > because of that reuse of ARGUMENT_PACK_SELECT tree.
> > > But I guess you're right, if there is a flag added to it only set by
> > > satisfy_fold which needs to create them immutable because there is the
> > > satisfaction cache etc., it might work. Will try that soon.
> >
> > With following incremental patch I've made some progress, but still
> > something to debug...
>
> One thing which needs solving is
>
> // P2963R3 - Ordering of constraints involving fold expressions
> // { dg-do compile { target c++20 } }
>
> template <class ...T> concept C = (__is_same (T, int) && ...);
> template <typename V>
> struct S {
> template <class ...U> requires (C<U...>)
> static constexpr bool foo () { return true; }
> };
>
> static_assert (S<void>::foo <int, int, int, int> ());
>
> somehow the template parameter mapping needs to be remembered even for the
> fold expanded constraint, right now the patch will see the pack is T,
> which is level 1 index 0, but args aren't arguments of the C concept,
> but of the foo function template.
> One can also use requires (C<int, int, int>) etc., no?
It seems the problem is FOLD_EXPR_PACKS is currently set to the
parameter packs used inside the non-normalized constraints, but I think
what we really need are the packs used in the normalized constraints,
specifically the packs used in the target of each parameter mapping of
each atomic constraint?
