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?

        Jakub

Reply via email to