On Thu, Oct 24, 2024 at 04:29:02PM -0400, Patrick Palka wrote:
> On Wed, 23 Oct 2024, Jason Merrill wrote:
>
> > On 10/23/24 10:20 AM, Patrick Palka wrote:
> > > On Tue, 22 Oct 2024, Marek Polacek wrote:
> > >
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > > > -- >8 --
> > > > This patch implements C++26 Pack Indexing, as described in
> > > > <https://wg21.link/P2662R3>.
> > > >
> > > > The issue discussing how to mangle pack indexes has not been resolved
> > > > yet <https://github.com/itanium-cxx-abi/cxx-abi/issues/175> and I've
> > > > made no attempt to address it so far.
> > > >
> > > > Rather than introducing a new template code for a pack indexing, I'm
> > > > adding a new operand to EXPR_PACK_EXPANSION to store the index; for
> > > > TYPE_PACK_EXPANSION, I'm stashing the index into TYPE_VALUES_RAW. This
> > >
> > > What are the pros and cons of reusing TYPE/EXPR_PACK_EXPANSION instead
> > > of creating two new tree codes for these operators (one of whose
> > > operands would itself be a bare TYPE/EXPR_PACK_EXPANSION)?
> > >
> > > I feel a little iffy at first glance about reusing these tree codes
> > > since it muddles what "kind" of tree they are: currently they represent
> > > a _vector_ or types/exprs (which is reflected by their tcc_exceptional
> > > class), and with this approach they can now also represent a single
> > > type/expr (despite their tcc_exceptional class), depending on whether
> > > PACK_EXPANSION_INDEX is set.
>
> Oops, I just noticed that TYPE/EXPR_PACK_EXPANSION are tcc_type/expr
> rather than tcc_exceptional, somewhat surprisingly. I must've been
> thinking about ARGUMENT_PACK_SELECT which is tcc_exceptional. But I
> guess conceptually they still represent a vector of types/exprs rather
> than a single type/expr currently.
>
> >
> > Yeah, I made a similar comment.
>
> FWIW there's an interesting example mentioned in
> https://github.com/itanium-cxx-abi/cxx-abi/issues/175:
>
> template <class... T> struct tuple {
> template <unsigned I> T...[I] get();
> };
>
> tuple<int, char, bool> t;
I've added that test in the v2 patch.
> How should we represent the partial instantiation of T...[I] with
> T={int, char, bool}? IIUC with the current approach we could use
> PACK_EXPANSION_EXTRA_ARGS to defer expansion until the index is known.
>
> With new tree codes, e.g. PACK_INDEX_EXPR/TYPE, if we represent the
> pack/pattern itself as a *_PACK_EXPANSION operand we could just
> expand that immediately, yielding a TREE_VEC operand. (And this
> expansion shouldn't allocate due to the T... optimization in
> tsubst_pack_expansion.)
What happens now is that we see that the index is value-dep and so
tsubst_pack_index just returns the original pack index. I'm not
sure I've done that correctly.
Thanks,
Marek
