[PR87322] move cp_evaluated up to tsubst all lambda parms
commit60378a964a2a6b32b9d05de053e181d691f68d52
authorAlexandre Oliva <aoliva@redhat.com>
Wed, 13 Feb 2019 17:42:39 +0000 (13 17:42 +0000)
committerAlexandre Oliva <aoliva@gcc.gnu.org>
Wed, 13 Feb 2019 17:42:39 +0000 (13 17:42 +0000)
tree15235c60c3d0ca6c9c6eb290ebe34f1ff02366b9
parent2db698cefc5b7e2a66ca64d8485dd9156ee7442f
[PR87322] move cp_evaluated up to tsubst all lambda parms

A lambda capture variable initialized with a lambda expr taking more
than one parameter got us confused.

The first problem was that the parameter list was cut short during
tsubsting because we tsubsted it with cp_unevaluated_operand.  We
reset it right after, to tsubst the function body, so I've moved the
reset up so that it's in effect while processing the parameters as
well.

The second problem was that the lambda expr appeared twice, once in a
decltype that gave the capture variable its type, and once in its
initializer.  This caused us to instantiate two separate lambda exprs
and closure types, and then to flag that the lambda expr in the
initializer could not be converted to the unrelated closure type
determined for the capture variable.  Recording the tsubsted expr in
the local specialization map, and retrieving it for reuse fixed it.
However, that required some care to avoid reusing the lambda expr
across different indices in pack expansions.

for  gcc/cp/ChangeLog

PR c++/87322
* pt.c (tsubst_lambda_expr): Avoid duplicate tsubsting.
Move cp_evaluated resetting before signature tsubsting.
(gen_elem_of_pack_expansion_instantiation): Separate local
specializations per index.

for  gcc/testsuite/ChangeLog

PR c++/87322
* g++.dg/cpp1y/pr87322.C: New.
* g++.dg/cpp0x/lambda/lambda-variadic5.C: Test that we
instantiate the expected number of lambda functions.

From-SVN: r268850
gcc/cp/ChangeLog
gcc/cp/pt.c
gcc/testsuite/ChangeLog
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic5.C
gcc/testsuite/g++.dg/cpp1y/pr87322.C [new file with mode: 0644]