We extend the behavior for local functions and methods of local classes
to lambdas in variable initializers. The initializer is not a separate
scope, but we treat it as such.
We also remove the (faulty) instantiation of default arguments in
TreeTransform::TransformLambdaExpr, because it doesn't do proper
initialization, and if it did, we would do it twice (and thus also emit
eventual errors twice).
This logic shouldn't even be here in the first place.. this should all be handled by SubstParmVarDecl in SemaTemplateInstantiate. It's wrong for TreeTransform to be assuming that TransformFunctionProtoType will have built new function parameters -- it doesn't do so by default, so in the non-template-instantiation case, this is clobbering the default argument information on the original lambda. And in the template instantiation case, this is clobbering the default argument information (including initialization) that SubstParmVarDecl already did.
Please try deleting this loop entirely. If there are still problems (and I think there are: I don't think we handle delayed instantiation for default argument in generic lambdas properly), we should address them by changing how we do default argument instantiation in SubstParmVarDecl. In particular, where that function calls SetParamDefaultArgument after calling SubstExpr, we should presumably instead be calling setUninstantiatedDefaultArg on the parameter if it's a parameter of a generic lambda (we still need to instantiate the default argument with the template arguments of the actual lambda call operator).