aboutsummaryrefslogtreecommitdiff
path: root/test/SemaCXX/lambda-expressions.cpp
AgeCommit message (Collapse)Author
2012-12-06Sema: Don't emit a warning when __func__ is used in a lambda outside of a ↵Benjamin Kramer
function. Fixes PR14518. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169510 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-24Update regression tests for r166617.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166619 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-20DR1472: A reference isn't odr-used if it has preceding initialization,Richard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166361 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-20Handle lambdas where the lambda-declarator is an explicit "(void)". PR13854.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164274 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-18Add an extra check for invalid decls in the lambda semantic analysis to ↵Eli Friedman
avoid a crash. PR13860. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164168 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-08Implement warning for integral null pointer constants other than the literal 0.David Blaikie
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161501 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-25PR12057: Allow variadic template pack expansions to cross lambda boundaries.Richard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160705 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-04Fixes some test cases that should have come along with r157943.Aaron Ballman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@157947 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-13Make the error about assigning to lambda-captured variablesJohn McCall
clearer, and mention the existence of mutable lambdas. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152598 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-13Alternate fix to PR12248: put Sema in charge of special-casingJohn McCall
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152593 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-12Make sure we treat variables captured by reference in lambda as modifiable ↵Eli Friedman
lvalues. Regression from r152491. Fixes PR12248. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152573 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-02Ensure that we instantiate static reference data members of class templatesRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151881 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-24Remove FIXME: as Eli points out, the behavior here is now correct.Richard Smith
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151405 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-24When checking whether a reference to a variable is an ICE, look at the type ofRichard Smith
the declaration, not at the type of the DeclRefExpr, since within a lambda the DeclRefExpr can be more const than the declaration is. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151399 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-21Only pop the expression evaluation context corresponding to a lambdaDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151082 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-18Rewrite variable capture within lambda expressions and blocks,Douglas Gregor
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
2012-02-12Within the body of a lambda expression, decltype((x)) for anDouglas Gregor
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
2012-02-09Implement return type deduction for lambdas per C++11Douglas Gregor
[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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150168 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-09Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor
and rapidly becoming untrue. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150165 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-09Various interrelated cleanups for lambdas:Douglas Gregor
- 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150123 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-06Fix the result of VarDecl::checkInitIsICE so it is consistently accurate in ↵Eli Friedman
C++11 mode. PR11928. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149908 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-03Make explicit captures which cause implicit captures work correctly.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149719 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-03Implement implicit capture for lambda expressions.Eli Friedman
Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149718 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01Introduce the lambda scope before determining explicit captures, whichDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149516 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01Improve checking of explicit captures in a C++11 lambda expression:Douglas Gregor
- 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149462 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26Add an additional testcase for a lambda with implicit void return type.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149034 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-26Refactor to share code for handling return statements between lambda ↵Eli Friedman
expressions and block literals. As it turns out, almost all the logic can be shared. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149031 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-07More lambda work: semantic analysis of capturing 'this'. It's a bit ↵Eli Friedman
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.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147723 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-07Lambdas: semantic analysis of explicit captures.Eli Friedman
This patch (and some of my other commits related to lambdas) is heavily based off of John Freeman's work-in-progress patches. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147706 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-05-03 04:58:51 +0000