History log of /external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
8e8fb3be5bd78f0564444eca02b404566a5f3b5d 19-Oct-2012 Andy Gibbs <andyg1001@hotmail.co.uk> Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166280 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
999713eea940f4e087cc3ac878689c5c5c7a7225 18-Feb-2012 Douglas Gregor <dgregor@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150875 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
68932845a432d2a1dbbc57a84fd85bbb37c90487 18-Feb-2012 Douglas Gregor <dgregor@apple.com> Unify our computation of the type of a captured reference to a
variable; it was previously duplicated, and one of the copies failed
to account for outer non-mutable lambda captures.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150872 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
bd64520ca4e4d4c531637d311f8ea384c912fce8 17-Feb-2012 Douglas Gregor <dgregor@apple.com> Only add 'const' to the type of variables captured in a lambda when
we're capturing it by value in a non-mutable lambda.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150791 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
f8af98286022f72157d84951b48fde5fb369ab29 12-Feb-2012 Douglas Gregor <dgregor@apple.com> 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.




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150347 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp