[Bug c++/126546] [c++26] [reflection] reflect-expression rejects pack-index-specifier operand (^^Ts...[0])

"cvs-commit at gcc dot gnu.org via Gcc-bugs" <[email protected]> Mon, 03 Aug 2026 21:19:16 +0000
Newsgroups gmane.comp.gcc.bugs
Message-ID <[email protected]/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D126546

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <[email protected]>:

https://gcc.gnu.org/g:78b03e2296722df3b69f28677cbeed03c1642dbf

commit r17-2909-g78b03e2296722df3b69f28677cbeed03c1642dbf
Author: Marek Polacek <[email protected]>
Date:   Mon Aug 3 13:02:01 2026 -0400

    c++/reflection: ^^ rejects pack-index-specifier [PR126546]

    [expr.reflect] says that a reflection of a pack-index-expressions
    is ill-formed.  But that applies to the ^^id-expression production,
    not ^^type-id, in which a pack-index-specifier (for types) can be
    used.  So it's wrong for get_reflection to check PACK_INDEX_P, it
    should only reject PACK_INDEX_EXPR.

    I don't think that currently we can get there with a PACK_INDEX_EXPR
    though: for a pack-index-expression Xs...[0] cp_parser_reflection_name
    will consume Xs and then immediately call get_reflection which gives
    an error.  But leaving the PACK_INDEX_EXPR check in doesn't seem like
    a bad idea.

            PR c++/126546

    gcc/cp/ChangeLog:

            * reflect.cc (get_reflection): Check PACK_INDEX_EXPR instead of
            PACK_INDEX_P.

    gcc/testsuite/ChangeLog:

            * g++.dg/reflect/pack-index1.C: Accept a reflection of a
            pack-index-specifier.  Reject a reflection of a
            pack-index-expression.
            * g++.dg/reflect/pack-index2.C: New test.

    Reviewed-by: Jason Merrill <[email protected]>=