c++: find_template_parameters and PARM_DECLs [PR105797]
authorPatrick Palka <ppalka@redhat.com>
Fri, 3 Jun 2022 13:08:41 +0000 (09:08 -0400)
committerPatrick Palka <ppalka@redhat.com>
Fri, 3 Jun 2022 13:08:41 +0000 (09:08 -0400)
commitdf4f95dbd4764ffc1e8270e5b3c0fd71b6724562
tree7d9eefc872aebaaafc6c3a8c28cfd0b22fa98d80
parent1982fe2692b6c3b7f969ffc4edac59f9d4359e91
c++: find_template_parameters and PARM_DECLs [PR105797]

As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two
equivalent expressions (according to cp_tree_equal) must use the same
template parameters (according to find_template_parameters).  This
assumption turned out to not hold for TARGET_EXPR, which was addressed
by that commit.

But this assumption apparently doesn't hold for PARM_DECL either:
find_template_parameters walks its DECL_CONTEXT but cp_tree_equal by
default doesn't consider DECL_CONTEXT unless comparing_specializations
is set.  Thus in the first testcase below, the atomic constraints of #1
and #2 are equivalent according to cp_tree_equal, but according to
find_template_parameters the former uses T and the latter uses both T
and U (surprisingly).

We could fix this assumption violation by setting comparing_specializations
in the atom_hasher, which would make cp_tree_equal return false for the
two atoms, but that seems overly pessimistic here.  Ideally the atoms
should continue being considered equivalent and we instead fix
find_template_paremeters to return just T for #2's atom.

To that end this patch makes for_each_template_parm_r stop walking the
DECL_CONTEXT of a PARM_DECL.  This should be safe to do because
tsubst_copy / tsubst_decl only substitutes the TREE_TYPE of a PARM_DECL
and doesn't bother substituting the DECL_CONTEXT, thus the only relevant
template parameters are those used in its type.  any_template_parm_r is
currently responsible for walking its TREE_TYPE, but I suppose it now makes
sense for for_each_template_parm_r to do so instead.

In passing this patch also makes for_each_template_parm_r stop walking
the DECL_CONTEXT of a VAR_/FUNCTION_DECL since doing so after walking
DECL_TI_ARGS is redundant, I think.

I experimented with not walking DECL_CONTEXT for CONST_DECL, but the
second testcase below demonstrates it's necessary to walk it.

PR c++/105797

gcc/cp/ChangeLog:

* pt.cc (for_each_template_parm_r) <case FUNCTION_DECL, VAR_DECL>:
Don't walk DECL_CONTEXT.
<case PARM_DECL>: Likewise.  Walk TREE_TYPE.
<case CONST_DECL>: Simplify.
(any_template_parm_r) <case PARM_DECL>: Don't walk TREE_TYPE.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-decltype4.C: New test.
* g++.dg/cpp2a/concepts-memfun3.C: New test.
gcc/cp/pt.cc
gcc/testsuite/g++.dg/cpp2a/concepts-decltype4.C [new file with mode: 0644]
gcc/testsuite/g++.dg/cpp2a/concepts-memfun3.C [new file with mode: 0644]