If the lambda used 'this' without without capturing it, an error was
emitted, but the constant evaluator would still attempt to lookup the
capture, and failing to find it, dereference a null pointer.
This only happens in C++17 (as that's when lambdas were made
potentially-constexpr). Therefore, I also updated the
lambda-expressions.cpp test to run in both C++14 and C++17 modes.
and returned to the context in which 'this' should be captured.
This means we now always mark 'this' referenced from the context in
which it's actually referenced, rather than potentially from some
context nested within that.
llvm-svn: 362182
Previously, we would:
* compute the type of the conversion function and static invoker as a
side-effect of template argument deduction for a conversion
* re-compute the type as part of deduced return type deduction when building
the conversion function itself
Neither of these turns out to be quite correct. There are other ways to reach a
declaration of the conversion function than in a conversion (such as an
explicit call or friend declaration), and performing auto deduction causes the
function type to be rebuilt in the context of the lambda closure type (which is
different from the context in which it originally appeared, resulting in
spurious substitution failures for constructs that are valid in one context but
not the other, such as the use of an enclosing class's "this" pointer).
This patch switches us to use a different strategy: as before, we use the
declared type of the operator() to form the type of the conversion function and
invoker, but we now populate that type as part of return type deduction for the
conversion function. And the invoker is now treated as simply being an
implementation detail of building the conversion function, and isn't given
special treatment by template argument deduction for the conversion function
any more.
llvm-svn: 321683
This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext)
Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node.
For e.g:
template<int> struct X { };
void f() {
const int N = 10;
X<N> x; // should be OK.
[] { return X<N>{}; }; // Should be OK - no capture - but clang errors!
}
See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627
In summary (and reiteration), the fix is as follows:
- Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right)
- Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext.
See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed.
Thanks Richard!
llvm-svn: 303492
This patch fixes an assertion that is triggered when RecordLayoutBuilder
tries to compute the size of a field (for capture "name" in the test
case) whose type hasn't been deduced. The patch fixes the bug by
correcting the typo of the capture initializer after the initializer is
parsed and before setting the expression for the annotation token.
Fixes PR30566.
rdar://problem/23380132
Differential Revision: https://reviews.llvm.org/D25206
llvm-svn: 290156
Previously, the failed capture of a variable in nested lambdas may crash when
the lambda pointer is null. Only give the note if a location can be retreived
from the lambda pointer.
llvm-svn: 262765
If a lambda used as default argument in a method declaration contained
a local class, that class was incorrectly recognized as nested class.
In this case compiler tried to postpone parsing of this class until
the enclosing class is finished, which caused crashes in some cases.
This change fixes PR13987.
Differential Revision: http://reviews.llvm.org/D11006
llvm-svn: 242132
Previously we would attempt to build a TypeSourceInfo for a null type,
and then we would forget to pop the function scope before returning an
error.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D6665
llvm-svn: 224271
for lambda expressions. That can't ever work; we need to transform the
parameters in order to create new ones in the new call operator context.
Fixes a rejects-valid when transforming a context containing a
lambda-expression that uses its function parameters in C++14 mode.
llvm-svn: 222482
type-dependent variable, even if the initializer isn't value-dependent. This
happens for ParenListExprs composed of non-value-dependent subexpressions, for
instance.
We should really give ParenListExprs (and InitListExprs) the type of the
initialized entity if they're used to represent a dependent initialization (and
if so, set them to be type-, value- and instantiation-dependent).
llvm-svn: 200954
handling C++11 default initializers. Without this, other parts of Sema (such as
lambda capture) would think the default initializer is part of the surrounding
function scope.
llvm-svn: 199453
When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191727
When nested lambdas are used in NSDMI's - this prevents infinite recursion.
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191645
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
llvm-svn: 166361
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
llvm-svn: 161501
Rather than adding a ContainsUnexpandedParameterPack bit to essentially every
AST node, we tunnel the bit directly up to the surrounding lambda expression
when we reach a context where an unexpanded pack can not normally appear.
Thus any statement or declaration within a lambda can now potentially contain
an unexpanded parameter pack.
llvm-svn: 160705
the diagnostic for assigning to a copied block capture. This has
the pleasant side-effect of letting us special-case the diagnostic
for assigning to a copied lambda capture as well, without introducing
a new non-modifiable enumerator for it.
llvm-svn: 152593
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.
llvm-svn: 151881
expression after we've finished the function body of the corresponding
function call operator. Otherwise, ActOnFinishFunctionBody() will see
the (unfinished) evaluation context of the lambda expression
itself. Fixes PR12031.
llvm-svn: 151082
eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
captures.
This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.
The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.
The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.
llvm-svn: 150875
id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:
1) Split out the check that determines whether we should capture a
particular variable reference, along with the computation of the
type of the field, from the actual act of capturing the
variable.
2) Always compute the result of decltype() within Sema, rather than
AST, because the decltype() computation is now context-sensitive.
llvm-svn: 150347
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.
llvm-svn: 150168
