Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is requir

Ensure that we instantiate static reference data members of class templates
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

show more ...

Remove FIXME: as Eli points out, the behavior here is now correct.

llvm-svn: 151405

When checking whether a reference to a variable is an ICE, look at the type of
the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the de

When checking whether a reference to a variable is an ICE, look at the type of
the declaration, not at the type of the DeclRefExpr, since within a lambda the
DeclRefExpr can be more const than the declaration is.

llvm-svn: 151399

show more ...

Only pop the expression evaluation context corresponding to a lambda
expression after we've finished the function body of the corresponding
function call operator. Otherwise, ActOnFinishFunctionBody(

Only pop the expression evaluation context corresponding to a lambda
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

show more ...

Rewrite variable capture within lambda expressions and blocks,
eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
ca

Rewrite variable capture within lambda expressions and blocks,
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

show more ...

Within the body of a lambda expression, decltype((x)) for an
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

Within the body of a lambda expression, decltype((x)) for an
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

show more ...

Implement return type deduction for lambdas per C++11
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types m

Implement return type deduction for lambdas per C++11
[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

show more ...

Remove the "unsupported" error for lambda expressions. It's annoying,
and rapidly becoming untrue.

llvm-svn: 150165

Various interrelated cleanups for lambdas:
- Complete the lambda class when we finish the lambda expression
(previously, it was left in the "being completed" state)
- Actually return the Lamb

Various interrelated cleanups for lambdas:
- Complete the lambda class when we finish the lambda expression
(previously, it was left in the "being completed" state)
- Actually return the LambdaExpr object and bind to the resulting
temporary when needed.
- Detect when cleanups are needed while capturing a variable into a
lambda (e.g., due to default arguments in the copy constructor), and
make sure those cleanups apply for the whole of the lambda
expression.


llvm-svn: 150123

show more ...

Fix the result of VarDecl::checkInitIsICE so it is consistently accurate in C++11 mode. PR11928.

llvm-svn: 149908

Make explicit captures which cause implicit captures work correctly.

llvm-svn: 149719

Implement implicit capture for lambda expressions.

Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.

llvm-svn: 14

Implement implicit capture for lambda expressions.

Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.

llvm-svn: 149718

show more ...

Introduce the lambda scope before determining explicit captures, which
cleans up and improves a few things:
- We get rid of the ugly dance of computing all of the captures in
data structures that

Introduce the lambda scope before determining explicit captures, which
cleans up and improves a few things:
- We get rid of the ugly dance of computing all of the captures in
data structures that clone those of CapturingScopeInfo, centralizing
the logic for accessing/updating these data structures
- We re-use the existing capture logic for 'this', which actually
works now.

Cleaned up some diagnostic wording in minor ways as well.

llvm-svn: 149516

show more ...

Improve checking of explicit captures in a C++11 lambda expression:
- Actually building the var -> capture mapping properly (there was an off-by-one error)
- Keeping track of the source location

Improve checking of explicit captures in a C++11 lambda expression:
- Actually building the var -> capture mapping properly (there was an off-by-one error)
- Keeping track of the source location of each capture
- Minor QoI improvements, e.g, highlighing the prior capture if
there are multiple captures, pointing at the variable declaration we
found if we reject it.

As part of this, add standard citations for the various semantic
checks we perform, and note where we're not performing those checks as
we should.

llvm-svn: 149462

show more ...

Add an additional testcase for a lambda with implicit void return type.

llvm-svn: 149034

Refactor to share code for handling return statements between lambda expressions and block literals. As it turns out, almost all the logic can be shared.

llvm-svn: 149031

More lambda work: semantic analysis of capturing 'this'. It's a bit complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Ac

More lambda work: semantic analysis of capturing 'this'. It's a bit complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)

llvm-svn: 147723

show more ...

Lambdas: semantic analysis of explicit captures.

This patch (and some of my other commits related to lambdas) is heavily based off of John Freeman's work-in-progress patches.

llvm-svn: 147706