On 10/24/24 4:29 PM, 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;
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.
As I just commented there, I would expect mangling of T...[I] to just
refer to the two template parameters, now that mangling properly
distinguishes template parameters at different depths. Using
PACK_EXPANSION_EXTRA_ARGS would be consistent with that.
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.)
At the same time, the pattern of a generic *_PACK_EXPANSION can be
anything whereas for these index operators we know it's always a single
bare pack, so we also don't need the full expressivity of
*_PACK_EXPANSION to represent these operators either.
I imagine that someone will want to extend it to indexing into an arbitrary
pack expansion before long, so I wouldn't try too hard to simplify based on
that assumption.
Jason
