summaryrefslogtreecommitdiffstats
path: root/clang/lib
diff options
context:
space:
mode:
authorFaisal Vali <faisalv@yahoo.com>2017-05-02 20:56:34 +0000
committerFaisal Vali <faisalv@yahoo.com>2017-05-02 20:56:34 +0000
commit999f27e3739efbe43edd1baa09dedd9dcea68d6f (patch)
treea8917fe0ceede6935aa02b2275b47826e6abab0e /clang/lib
parentc7695a8e4565afb256aad1a705ef292bc3625a36 (diff)
downloadbcm5719-llvm-999f27e3739efbe43edd1baa09dedd9dcea68d6f.tar.gz
bcm5719-llvm-999f27e3739efbe43edd1baa09dedd9dcea68d6f.zip
Fix PR32831 (Try Again): 'this' capture while instantiating generic lambda call operator specialization
When computing the appropriate cv-qualifiers for the 'this' capture, we have to examine each enclosing lambda - but when using the FunctionScopeInfo stack we have to ensure that the lambda below (outer) is the decl-context of the closure-class of the current lambda. https://bugs.llvm.org/show_bug.cgi?id=32831 This patch was initially committed here: https://reviews.llvm.org/rL301735 Then reverted here: https://reviews.llvm.org/rL301916 The issue with the original patch was a failure to check that the closure type has been created within the LambdaScopeInfo before querying its DeclContext - instead of just assuming it has (silly!). A reduced example such as this highlights the problem: struct X { int data; auto foo() { return [] { return [] -> decltype(data) { return 0; }; }; } }; When 'data' within decltype(data) tries to determine the type of 'this', none of the LambdaScopeInfo's have their closure types created at that point. llvm-svn: 301972
Diffstat (limited to 'clang/lib')
-rw-r--r--clang/lib/Sema/SemaExprCXX.cpp53
1 files changed, 39 insertions, 14 deletions
diff --git a/clang/lib/Sema/SemaExprCXX.cpp b/clang/lib/Sema/SemaExprCXX.cpp
index d65570fcef7..9b88cddbc96 100644
--- a/clang/lib/Sema/SemaExprCXX.cpp
+++ b/clang/lib/Sema/SemaExprCXX.cpp
@@ -901,17 +901,36 @@ static QualType adjustCVQualifiersForCXXThisWithinLambda(
// capturing lamdbda's call operator.
//
- // The issue is that we cannot rely entirely on the FunctionScopeInfo stack
- // since ScopeInfos are pushed on during parsing and treetransforming. But
- // since a generic lambda's call operator can be instantiated anywhere (even
- // end of the TU) we need to be able to examine its enclosing lambdas and so
- // we use the DeclContext to get a hold of the closure-class and query it for
- // capture information. The reason we don't just resort to always using the
- // DeclContext chain is that it is only mature for lambda expressions
- // enclosing generic lambda's call operators that are being instantiated.
-
+ // Since the FunctionScopeInfo stack is representative of the lexical
+ // nesting of the lambda expressions during initial parsing (and is the best
+ // place for querying information about captures about lambdas that are
+ // partially processed) and perhaps during instantiation of function templates
+ // that contain lambda expressions that need to be transformed BUT not
+ // necessarily during instantiation of a nested generic lambda's function call
+ // operator (which might even be instantiated at the end of the TU) - at which
+ // time the DeclContext tree is mature enough to query capture information
+ // reliably - we use a two pronged approach to walk through all the lexically
+ // enclosing lambda expressions:
+ //
+ // 1) Climb down the FunctionScopeInfo stack as long as each item represents
+ // a Lambda (i.e. LambdaScopeInfo) AND each LSI's 'closure-type' is lexically
+ // enclosed by the call-operator of the LSI below it on the stack (while
+ // tracking the enclosing DC for step 2 if needed). Note the topmost LSI on
+ // the stack represents the innermost lambda.
+ //
+ // 2) If we run out of enclosing LSI's, check if the enclosing DeclContext
+ // represents a lambda's call operator. If it does, we must be instantiating
+ // a generic lambda's call operator (represented by the Current LSI, and
+ // should be the only scenario where an inconsistency between the LSI and the
+ // DeclContext should occur), so climb out the DeclContexts if they
+ // represent lambdas, while querying the corresponding closure types
+ // regarding capture information.
+
+ // 1) Climb down the function scope info stack.
for (int I = FunctionScopes.size();
- I-- && isa<LambdaScopeInfo>(FunctionScopes[I]);
+ I-- && isa<LambdaScopeInfo>(FunctionScopes[I]) &&
+ (!CurLSI || !CurLSI->Lambda || CurLSI->Lambda->getDeclContext() ==
+ cast<LambdaScopeInfo>(FunctionScopes[I])->CallOperator);
CurDC = getLambdaAwareParentOfDeclContext(CurDC)) {
CurLSI = cast<LambdaScopeInfo>(FunctionScopes[I]);
@@ -927,11 +946,17 @@ static QualType adjustCVQualifiersForCXXThisWithinLambda(
return ASTCtx.getPointerType(ClassType);
}
}
- // We've run out of ScopeInfos but check if CurDC is a lambda (which can
- // happen during instantiation of generic lambdas)
+
+ // 2) We've run out of ScopeInfos but check if CurDC is a lambda (which can
+ // happen during instantiation of its nested generic lambda call operator)
if (isLambdaCallOperator(CurDC)) {
- assert(CurLSI);
- assert(isGenericLambdaCallOperatorSpecialization(CurLSI->CallOperator));
+ assert(CurLSI && "While computing 'this' capture-type for a generic "
+ "lambda, we must have a corresponding LambdaScopeInfo");
+ assert(isGenericLambdaCallOperatorSpecialization(CurLSI->CallOperator) &&
+ "While computing 'this' capture-type for a generic lambda, when we "
+ "run out of enclosing LSI's, yet the enclosing DC is a "
+ "lambda-call-operator we must be (i.e. Current LSI) in a generic "
+ "lambda call oeprator");
assert(CurDC == getLambdaAwareParentOfDeclContext(CurLSI->CallOperator));
auto IsThisCaptured =
OpenPOWER on IntegriCloud