aboutsummaryrefslogtreecommitdiff
path: root/gcc/combine.c
diff options
context:
space:
mode:
authorPatrick Palka <ppalka@redhat.com>2020-04-23 17:29:55 -0400
committerPatrick Palka <ppalka@redhat.com>2020-04-23 17:29:55 -0400
commitf9f166251f181ddcee64092d89aecbc1166ca706 (patch)
tree8f378f0c2f476461596a4449aebabed0482a84db /gcc/combine.c
parentb78868459fda4de0417e52e1d46388ca75a4e74d (diff)
downloadgcc-f9f166251f181ddcee64092d89aecbc1166ca706.zip
gcc-f9f166251f181ddcee64092d89aecbc1166ca706.tar.gz
gcc-f9f166251f181ddcee64092d89aecbc1166ca706.tar.bz2
c++: Lambda in friend of constrained class [PR94645]
In the testcase below, when grokfndecl processes the operator() decl for the lambda inside the friend function foo, processing_template_decl is rightly 1, but template_class_depth on the lambda's closure type incorrectly returns 0 instead of 1. Since processing_template_decl > template_class_depth, this makes grokfndecl think that the operator() has its own set of template arguments, and so we attach the innermost set of constraints -- those belonging to struct l -- to the operator() decl. We then get confused when checking constraints_satisfied_p on the operator() because it doesn't have template information and yet has constraints associated with it. This patch fixes template_class_depth to return the correct template nesting level in cases like these, in that when it hits a friend function it walks into the DECL_FRIEND_CONTEXT of the friend rather than into the CP_DECL_CONTEXT. gcc/cp/ChangeLog: PR c++/94645 * pt.c (template_class_depth): Walk into the DECL_FRIEND_CONTEXT of a friend declaration rather than into its CP_DECL_CONTEXT. gcc/testsuite/ChangeLog: PR c++/94645 * g++.dg/cpp2a/concepts-lambda6.C: New test.
Diffstat (limited to 'gcc/combine.c')
0 files changed, 0 insertions, 0 deletions