Test case (-std=c++2a): template <int N> concept foo = [](auto) constexpr -> bool { return true; }(N); bool a = foo<2>; Extended test case (use lambda in concept to turn integer into index sequence): #include <utility> template <int N> concept foo = []<std::size_t... Is>(std::index_sequence<Is...>) constexpr { return (Is + ...) > 10; }(std::make_index_sequence<N>()); bool a = foo<7>; If I read the standard correctly, both test cases are well-formed and should work: P0315R4 started to allow lambdas in unevaluated contexts (https://eel.is/c++draft/temp.concept#6). On a slight tangent: I believe substitution failures on instantiation of the lambda are not ill-formed, even though P0315R4 seemed to intend that outcome. While I would love to use it to SFINAE test structured bindings, I think this is rather a defect in the current WD, no?
*** Bug 95324 has been marked as a duplicate of this bug. ***
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:020d86db8896f088435830595640e6fc21bc64ad commit r11-723-g020d86db8896f088435830595640e6fc21bc64ad Author: Patrick Palka <ppalka@redhat.com> Date: Fri May 29 09:40:40 2020 -0400 c++: lambdas inside constraints [PR92652] When parsing a constraint-expression, a requires-clause or a requires-expression, we temporarily increment processing_template_decl so that we always obtain template trees which we could later reduce via substitution even when not inside a template. But incrementing processing_template_decl when we're already inside a template has the unintended side effect of shifting up the template parameter levels of a lambda defined inside one of these constructs, which leads to confusion later during substitution into the lambda. This patch fixes this issue by incrementing processing_template_decl during parsing of these constructs only if it is 0. Passes 'make check-c++', and also tested by building cmcstl2, does this look OK to commit after a full bootstrap/regtest? gcc/cp/ChangeLog: PR c++/92652 PR c++/93698 PR c++/94128 * parser.c (cp_parser_requires_clause_expression): Temporarily increment processing_template_decl only if it is 0. (cp_parser_constraint_expression): Likewise. (cp_parser_requires_expression): Likewise. gcc/testsuite/ChangeLog: PR c++/92652 PR c++/93698 PR c++/94128 * g++.dg/cpp2a/concepts-lambda8.C: New test. * g++.dg/cpp2a/concepts-lambda9.C: New test. * g++.dg/cpp2a/concepts-lambda10.C: New test.
The releases/gcc-10 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:03c344ad180e094140be514a5e7cbaf95b5dcd2e commit r10-8214-g03c344ad180e094140be514a5e7cbaf95b5dcd2e Author: Patrick Palka <ppalka@redhat.com> Date: Fri May 29 14:17:02 2020 -0400 c++: lambdas inside constraints [PR92652] When parsing a constraint-expression, a requires-clause or a requires-expression, we temporarily increment processing_template_decl so that we always obtain template trees which we could later reduce via substitution even when not inside a template. But incrementing processing_template_decl when we're already inside a template has the unintended side effect of shifting up the template parameter levels of a lambda defined inside one of these constructs, which leads to confusion later during substitution into the lambda. This patch fixes this issue by incrementing processing_template_decl during parsing of these constructs only if it is 0. gcc/cp/ChangeLog: PR c++/92652 PR c++/93698 PR c++/94128 * parser.c (cp_parser_requires_clause_expression): Temporarily increment processing_template_decl only if it is 0. (cp_parser_constraint_expression): Likewise. (cp_parser_requires_expression): Likewise. gcc/testsuite/ChangeLog: PR c++/92652 PR c++/93698 PR c++/94128 * g++.dg/cpp2a/concepts-lambda8.C: New test. * g++.dg/cpp2a/concepts-lambda9.C: New test. * g++.dg/cpp2a/concepts-lambda10.C: New test. (cherry picked from commit 020d86db8896f088435830595640e6fc21bc64ad)
Fixed for GCC 10.2+.