https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122752
--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-15 branch has been updated by Patrick Palka <[email protected]>: https://gcc.gnu.org/g:bb061a3b815249f2a4f375c3f7c6ea88978b9804 commit r15-10611-gbb061a3b815249f2a4f375c3f7c6ea88978b9804 Author: Patrick Palka <[email protected]> Date: Mon Dec 15 14:30:53 2025 -0500 c++: nested typename type resolving to wildcard type [PR122752] Here typename A<S>::VertexSet::size_type within the out-of-line declaration is initially parsed at namespace scope, so the LHS A<S>::VertexSet is treated as a dependent name and represented as a TYPENAME_TYPE with tag_type as class_type.[1] Once we realize we're parsing a member declarator we call maybe_update_decl_type to reprocess the TYPENAME_TYPE relative to the class template scope, during which make_typename_type succeeds in resolving the lookup and returns the member typedef VertexSet (to the TEMPLATE_TYPE_PARM S). But then the caller tsubst complains that this result isn't a class type as per the tag_type. This patch just relaxes tsubst to allow TYPENAME_TYPE getting resolved to a wildcard type regardless of the tag_type. This does mean we lose information about the tag_type during a subsequent tsubst, but that's probably harmless (famous last words). [1]: The tag_type should probably be scope_type. Changing this seems to be a matter of changing cp_parser_qualifying_entity to pass scope_type instead of class_type, but I don't feel confident about that and it seems risky. I then got confused as to why that function passes none_type in the !type_p case; to me it should use scope_type unconditionally, but doing so breaks things. This approach seems safer to backport. PR c++/122752 gcc/cp/ChangeLog: * pt.cc (tsubst) <case TYPENAME_TYPE>: Allow TYPENAME_TYPE resolving to another wildcard type. gcc/testsuite/ChangeLog: * g++.dg/template/dependent-name19.C: New test. Reviewed-by: Jason Merrill <[email protected]> (cherry picked from commit 2bf057c53e97004034ed1528d850a214372305b8)
