[llvm-testresults] buildbot failure in lab.llvm.org on phase1 - sanity

[llvmlab-buildmaster at lab.llvm.org]

The Buildbot has detected a new failure on builder phase1 - sanity while building cfe.
Full details are available at:
 http://lab.llvm.org:8013/builders/phase1%20-%20sanity/builds/13162

Buildbot URL: http://lab.llvm.org:8013/

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 193216
Blamelist: faisalv

BUILD FAILED: failed

sincerely,
 -The Buildbot


================================================================================

CHANGES:
Files:
 lib/Sema/SemaTemplateInstantiate.cpp
 lib/Sema/SemaTemplateInstantiateDecl.cpp
 lib/Sema/TreeTransform.h
 test/CXX/expr/expr.prim/expr.prim.lambda/generic-lambda-unimplemented-1y.cpp
 test/SemaCXX/cxx1y-generic-lambdas.cpp
On: http://10.1.1.2/svn/llvm-project
For: cfe
At: Tue 22 Oct 2013 18:00:30
Changed By: faisalv
Comments: Again: Teach TreeTransform and family how to transform generic 
lambdas nested within templates and themselves.

A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted,


The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType.  This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off.
Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476.

The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created.   

This does not yet include capturing.

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
Properties: 




LOGS: