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
|