| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
and rapidly becoming untrue.
llvm-svn: 150165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
C++11 mode. PR11928.
llvm-svn: 149908
|
| |
|
|
| |
llvm-svn: 149719
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
llvm-svn: 149034
|
| |
|
|
|
|
| |
expressions and block literals. As it turns out, almost all the logic can be shared.
llvm-svn: 149031
|
| |
|
|
|
|
| |
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
|
|
|
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
|