On 02/21/2014 09:10 AM, Jason Merrill wrote:
While parsing the template parameter list for a lambda, we've already pushed into the closure class but haven't created the op() FUNCTION_DECL, so trying to capture 'this' by way of the 'this' pointer of op() breaks. Avoid the ICE by not trying to capture 'this' when parsing a parameter list.
On second thought, I'd rather not depend on the parsing state here, since we don't always update current_binding_level during template instantiation. So let's check for the actual problem instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5ca06118071f28b060b751415d18f8af4968a0a4 Author: Jason Merrill <ja...@redhat.com> Date: Fri Feb 21 15:06:47 2014 -0500 PR c++/60252 * lambda.c (maybe_resolve_dummy): Check lambda_function rather than current_binding_level. diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c index 7fe235b..277dec6 100644 --- a/gcc/cp/lambda.c +++ b/gcc/cp/lambda.c @@ -749,10 +749,8 @@ maybe_resolve_dummy (tree object) if (type != current_class_type && current_class_type && LAMBDA_TYPE_P (current_class_type) - && DERIVED_FROM_P (type, current_nonlambda_class_type ()) - /* If we get here while parsing the parameter list of a lambda, it - will fail, so don't even try (c++/60252). */ - && current_binding_level->kind != sk_function_parms) + && lambda_function (current_class_type) + && DERIVED_FROM_P (type, current_nonlambda_class_type ())) { /* In a lambda, need to go through 'this' capture. */ tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type);