https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123810
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- gcc/cp/decl.cc.jj 2026-01-31 10:19:14.989335310 +0100
+++ gcc/cp/decl.cc 2026-02-03 17:56:44.311424585 +0100
@@ -13763,6 +13763,13 @@ name_unnamed_type (tree type, tree decl)
gcc_assert (TYPE_UNNAMED_P (type)
|| enum_with_enumerator_for_linkage_p (type));
+ /* For C++26, set TYPE_NAME to a copy of DECL rather than DECL itself,
+ so that after typedef struct { int s; } S;
+ is_type_alias (^^S) is true and dealias (^^S) is TYPE passed
+ to this function. */
+ if (flag_reflection)
+ decl = copy_decl (decl);
+
/* Replace the anonymous decl with the real decl. Be careful not to
rename other typedefs (such as the self-reference) of type. */
tree orig = TYPE_NAME (type);
fixes the ICE, but nothing actually sets DECL_CONTEXT of that TYPE_DECL copy
(in the
#include <meta>
struct S {
typedef enum { A, B } C;
};
int a = members_of (^^S, std::meta::access_context::unchecked ()).size ();
case to current_class_type, but it could be some NAMESPACE_DECL or
FUNCTION_DECL in other cases depending where such typedef appears.
And unsure if we arrange for the DECL_CONTEXT to be set at some point later if
the FE won't be upset that there will be this extra TYPE_DECL with DECL_CONTEXT
pointing to a RECORD_TYPE in whose TYPE_FIELDS chain that TYPE_DECL won't
appear though.
