On Sat, Feb 21, 2026 at 02:54:47PM +0900, Jason Merrill wrote: > > Various spots have been testing for the typedef name for linkage purposes > > cases and were using tests like: > > OVERLOAD_TYPE_P (TREE_TYPE (value)) > > && value == TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (value))) > > So that this can be tested, this patch introduces a new decl_flag on > > the TYPE_DECLs and marks for -freflection both of these TYPE_DECLs > > (and for -fno-reflection the one without IDENTIFIER_ANON_P name). > > It is easy to differentiate between the two, the first one is also > > DECL_IMPLICIT_TYPEDEF_P, the latter is not (and on the other side > > has DECL_ORIGINAL_TYPE non-NULL). > > For name lookup in namespaces, nothing special needs to be done, > > because the originally IDENTIFIER_ANON_P TYPE_DECL wasn't added > > to the bindings, > > Hmm, do other unnamed decls at namespace scope show up in members_of?
We handle anonymous unions at namespace scope right now, but only if the anon union contains at least one member - by handling the DECL_ANON_UNION_VAR_P vars - if it doesn't have any, it is pedantically invalid C++ and we don't have any traces of it in the namespace. > > eval_annotations_of right now does maybe_strip_typedefs and for types > > uses TYPE_ATTRIBUTES, so it will never return annotations on type aliases, > > guess we'll need to figure out what exactly it should do for cases like > > that. > > Sounds like the maybe_strip_typedefs is wrong, since reflection in general > tries to preserve aliases. Actually the maybe_strip_typedefs call is correct, that is for the type argument (so when it is std::meta::annotations_with_type) and the standard says that dealias should be used - https://eel.is/c++draft/meta.reflection#annotation-6.2 But we probably shouldn't use TYPE_ATTRIBUTES but DECL_ATTRIBUTES (TYPE_NAME (r)) if r is a type alias. I'll test a patch for that separately. > > (TYPE_DECL_NAMED_FOR_LINKAGE_PURPOSES_P): Likewise. > > Let's call this TYPE_DECL_WAS_UNNAMED to look more distinct from the first > new macro. Ok. > > @@ -13698,7 +13697,8 @@ maybe_diagnose_non_c_class_typedef_for_l > > { > > auto_diagnostic_group d; > > if (diagnose_non_c_class_typedef_for_linkage (type, orig)) > > - inform (DECL_SOURCE_LOCATION (TYPE_NAME (t)), > > + inform (type == t ? DECL_SOURCE_LOCATION (orig) > > + : DECL_SOURCE_LOCATION (TYPE_NAME (t)), > > This distinction doesn't seem that significant? Some tests in the testsuite would have to be changed otherwise when -freflection is changed to be on by default for C++26. The difference in that case is the locus of the unnamed struct vs. of the typedef name for linkage purposes. > > --- gcc/cp/name-lookup.cc.jj 2026-02-12 10:32:24.663330851 +0100 > > +++ gcc/cp/name-lookup.cc 2026-02-12 13:38:47.498316544 +0100 > > @@ -1893,6 +1893,11 @@ fields_linear_search (tree klass, tree n > > continue; > > } > > + if (TYPE_DECL_NAMED_FOR_LINKAGE_PURPOSES_P (decl)) > > + /* Ignore TYPE_DECLs formerly unnamed, there is a TYPE_DECL > > + for linkage purposes later on in the chain. */ > > For this and the identical comments below, it seems to me the point is > rather that this declaration doesn't really have a name as far as the > language is concerned, giving it a DECL_NAME is an internal detail that we > want to ignore in name lookup. Will change next week. Jakub
