diff options
author | Patrick Palka <ppalka@redhat.com> | 2020-04-23 17:29:55 -0400 |
---|---|---|
committer | Patrick Palka <ppalka@redhat.com> | 2020-04-23 17:29:55 -0400 |
commit | f9f166251f181ddcee64092d89aecbc1166ca706 (patch) | |
tree | 8f378f0c2f476461596a4449aebabed0482a84db /gcc/combine.c | |
parent | b78868459fda4de0417e52e1d46388ca75a4e74d (diff) | |
download | gcc-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