https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110927
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Patrick Palka <ppa...@gcc.gnu.org>: https://gcc.gnu.org/g:b3cfa47d385c004bfbf1772c41e255e8eb60377e commit r13-7729-gb3cfa47d385c004bfbf1772c41e255e8eb60377e Author: Patrick Palka <ppa...@redhat.com> Date: Fri Aug 11 13:26:02 2023 -0400 c++: dependently scoped template-id in type-req [PR110927] Here we're incorrectly rejecting the first type-requirement at parse time with concepts-requires35.C:14:56: error: âtypename A<T>::Bâ is not a template [-fpermissive] We also incorrectly reject the second type-requirement at satisfaction time with concepts-requires35.C:17:34: error: âtypename A<int>::Bâ names âtemplate<class U> struct A<int>::Bâ, which is not a type and similarly for the third type-requirement. This seems to happen only within a type-requirement; if we instead use e.g. an alias template then it works as expected. The difference ultimately seems to be that during parsing of a using-decl, we pass check_dependency_p=true to cp_parser_nested_name_specifier_opt whereas for a type-requirement we pass check_dependency_p=false. Passing =false causes cp_parser_template_id for the dependently-scoped template-id B<bool> to create a TYPE_DECL of TYPENAME_TYPE (with TYPENAME_IS_CLASS_P unexpectedly set in the last two cases) whereas passing =true causes it to return a TEMPLATE_ID_EXPR. We then call make_typename_type on this TYPE_DECL which does the wrong thing. Since there seems to be no justification for using check_dependency_p=false here, the simplest fix seems to be to pass check_dependency_p=true instead, matching the behavior of cp_parser_elaborated_type_specifier. PR c++/110927 gcc/cp/ChangeLog: * parser.cc (cp_parser_type_requirement): Pass check_dependency_p=true instead of =false. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires35.C: New test. (cherry picked from commit 63bd36be990f3b08fcee5b69718ef97c055fbb31)
