Compiling the following code with GCC trunk and flags: -std=c++20 ``` template<typename T> struct in_place_type_t {}; template<typename T> inline constexpr in_place_type_t<T> in_place_type; template<typename T, typename... Ts> inline constexpr bool outer_helper_v = true; template<typename... Ts> struct foo { struct type; template<typename U> static constexpr bool helper_v = outer_helper_v<U, Ts...>; }; template<typename... Ts> struct foo<Ts...>::type { template<typename U> requires helper_v<U> type(in_place_type_t<U>) {} }; int main() { foo<int>::type x(in_place_type<int>); } ``` results in an internal compiler-error ``` <source>: In substitution of 'template<class U> requires helper_v<U> foo<int>::type::type(in_place_type_t<T>) [with U = {int}]': <source>:26:40: required from here <source>:21:18: internal compiler error: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:13084 21 | requires helper_v<U> | ^~~~~~~~~~~ 0x1d4c179 internal_error(char const*, ...) ???:0 0x685746 tree_vec_elt_check_failed(int, int, char const*, int, char const*) ???:0 0x99e0bc tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) ???:0 0x9afa62 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ???:0 0x9b064b tsubst_argument_pack(tree_node*, tree_node*, int, tree_node*) ???:0 0x9afa04 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ???:0 0x983ebd tsubst(tree_node*, tree_node*, int, tree_node*) ???:0 0x7abcda constraints_satisfied_p(tree_node*, tree_node*) ???:0 0x9c26c3 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ???:0 0x74abc9 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, tree_node**, int) ???:0 0x74c8c0 build_special_member_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, int) ???:0 0x8611c8 build_aggr_init(tree_node*, tree_node*, int, int) ???:0 0x81f0d9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ???:0 0x94f36d c_parse_file() ???:0 0xad2922 c_common_parse_file() ???:0 ``` See https://godbolt.org/z/ebnxfsMs9 for an example.
Confirmed, started with r10-3735-gcb57504a55015891.
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:e3528ce197f8886869f95e8a8f901861a319851c commit r12-1989-ge3528ce197f8886869f95e8a8f901861a319851c Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jul 2 13:54:57 2021 -0400 c++: unqualified member template in constraint [PR101247] Here any_template_parm_r is failing to mark the template parameters implicitly used by the unqualified use of 'd' inside the constraint because the code to do so assumes each level of a template parameter list points to the corresponding primary template, but here the parameter level for A in the out-of-line definition of A::B does not (nor do the parameter levels for A and C in the definition of A::C), which causes us to overlook the sharing. So it seems we can't in general depend on the TREE_TYPE of a template parameter level being non-empty here. This patch partially fixes this by rewriting the relevant part of any_template_parm_r to not depend on the TREE_TYPE of outer levels. We still depend on the innermost level to point to the innermost primary template, so we still crash on the commented out line in the below testcase. PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Rewrite to use common_enclosing_class and to not depend on the TREE_TYPE of outer levels pointing to the corresponding primary template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: New test.
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:f53e66019df819f55d424cc56f8b0ea81c074b55 commit r12-2221-gf53e66019df819f55d424cc56f8b0ea81c074b55 Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jul 9 10:20:22 2021 -0400 c++: find_template_parameters and TEMPLATE_DECLs [PR101247] r12-1989 fixed the testcase in the PR, but unfortunately the fix is buggy: it breaks the case where the common template between the TEMPLATE_DECL t and ctx_parms is the innermost template (as in concepts-memtmpl5.C below). This can be fixed by instead passing the TREE_TYPE of ctmpl to common_enclosing_class when ctmpl is a class template. But even after that's fixed, the analogous case where the innermost template is a partial specialization is still broken (as in concepts-memtmpl5a.C below), because ctmpl is always a primary template. So this patch instead takes a diferent approach that doesn't rely on ctx_parms at all: when looking for the template parameters of a TEMPLATE_DECL that are shared with the current template context, just walk its DECL_CONTEXT. As long as the template is not overly general (e.g. we didn't pass it through most_general_template), this should give us exactly what we want, since if a TEMPLATE_DECL can be referred to from some template context then the template parameters it uses must all be in-scope and contained in its DECL_CONTEXT. This effectively makes us treat TEMPLATE_DECLs more similarly to other _DECLs (whose DECL_CONTEXT we also walk). PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Just walk the DECL_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: Uncomment the commented out example, which we now handle correctly. * g++.dg/cpp2a/concepts-memtmpl5.C: New test. * g++.dg/cpp2a/concepts-memtmpl5a.C: New test.
The releases/gcc-11 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:2902f2d8424cfa365fec49401fa066e2b6de9ca4 commit r11-8732-g2902f2d8424cfa365fec49401fa066e2b6de9ca4 Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jul 2 13:54:57 2021 -0400 c++: unqualified member template in constraint [PR101247] Here any_template_parm_r is failing to mark the template parameters implicitly used by the unqualified use of 'd' inside the constraint because the code to do so assumes each level of a template parameter list points to the corresponding primary template, but here the parameter level for A in the out-of-line definition of A::B does not (nor do the parameter levels for A and C in the definition of A::C), which causes us to overlook the sharing. So it seems we can't in general depend on the TREE_TYPE of a template parameter level being non-empty here. This patch partially fixes this by rewriting the relevant part of any_template_parm_r to not depend on the TREE_TYPE of outer levels. We still depend on the innermost level to point to the innermost primary template, so we still crash on the commented out line in the below testcase. PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Rewrite to use common_enclosing_class and to not depend on the TREE_TYPE of outer levels pointing to the corresponding primary template. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: New test. (cherry picked from commit e3528ce197f8886869f95e8a8f901861a319851c)
The releases/gcc-11 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:6d11dd94e53103641f9826b14e3086399f2a948c commit r11-8733-g6d11dd94e53103641f9826b14e3086399f2a948c Author: Patrick Palka <ppalka@redhat.com> Date: Fri Jul 9 10:20:22 2021 -0400 c++: find_template_parameters and TEMPLATE_DECLs [PR101247] r12-1989 fixed the testcase in the PR, but unfortunately the fix is buggy: it breaks the case where the common template between the TEMPLATE_DECL t and ctx_parms is the innermost template (as in concepts-memtmpl5.C below). This can be fixed by instead passing the TREE_TYPE of ctmpl to common_enclosing_class when ctmpl is a class template. But even after that's fixed, the analogous case where the innermost template is a partial specialization is still broken (as in concepts-memtmpl5a.C below), because ctmpl is always a primary template. So this patch instead takes a diferent approach that doesn't rely on ctx_parms at all: when looking for the template parameters of a TEMPLATE_DECL that are shared with the current template context, just walk its DECL_CONTEXT. As long as the template is not overly general (e.g. we didn't pass it through most_general_template), this should give us exactly what we want, since if a TEMPLATE_DECL can be referred to from some template context then the template parameters it uses must all be in-scope and contained in its DECL_CONTEXT. This effectively makes us treat TEMPLATE_DECLs more similarly to other _DECLs (whose DECL_CONTEXT we also walk). PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) <case TEMPLATE_DECL>: Just walk the DECL_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: Uncomment the commented out example, which we now handle correctly. * g++.dg/cpp2a/concepts-memtmpl5.C: New test. * g++.dg/cpp2a/concepts-memtmpl5a.C: New test. (cherry picked from commit f53e66019df819f55d424cc56f8b0ea81c074b55)
Fixed for GCC 11.2/12