[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]>=