On Fri, Jul 26, 2024 at 02:35:01PM -0400, Patrick Palka wrote:
> > IIUC the way gen_elem_of_pack_expansion_instantiation handles this for
> > ordinary pack expnasions is by replacing each ARGUMENT_PACK with an
> > ARGUMENT_PACK_SELECT. This ARGUMENT_PACK_SELECT contains the entire
> > pack as well as the current index into the pack, and it essentially
> > acts as an overloaded template argument that's treated either as a
> > single pack element or as the entire pack itself as needed.
>
> Ah but by using ARGUMENT_PACK_SELECT I bet you'll run into an
> iterative_hash_template_arg ICE when the satisfaction cache tries to
> hash it.
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.
Thanks.
> IMHO we should allow hashing/comparing ARGUMENT_PACK_SELECT, at least
> "immutable" ones whose index isn't expected to change from under us,
> accordin to some flag maybe. (the ARGUMENT_PACK_SELECTs created from
> gen_elem_of_pack_expansion_instantiation are reused/modified across
> iterations so those wouldn't be safe to store in a hash table.)
>
> >
> > On that note I wonder if there's any opportunity for code reuse from
> > gen_elem_of_pack_expansion_instantiation / tsubst_pack_expansion?
I think I'm not using too much code from those (yet) to make it worthwhile,
but am open to outline some helpers if needed.
Jakub
