summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/lambda-expressions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Classes inside lambdas are local not nested.Serge Pavlov2015-07-141-0/+30
| | | | | | | | | | | | | If a lambda used as default argument in a method declaration contained a local class, that class was incorrectly recognized as nested class. In this case compiler tried to postpone parsing of this class until the enclosing class is finished, which caused crashes in some cases. This change fixes PR13987. Differential Revision: http://reviews.llvm.org/D11006 llvm-svn: 242132
* PR21857: weaken an incorrect assertion.Richard Smith2015-02-111-0/+9
| | | | llvm-svn: 228785
* DR1048: drop top-level cv-qualifiers when deducing the return type of aRichard Smith2014-12-191-3/+1
| | | | | | lambda-expression in C++11, to match the C++14 rules. llvm-svn: 224620
* Handle errors in lambda prototype instantiation correctlyReid Kleckner2014-12-151-0/+14
| | | | | | | | | | | | Previously we would attempt to build a TypeSourceInfo for a null type, and then we would forget to pop the function scope before returning an error. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D6665 llvm-svn: 224271
* Remove code that tries to avoid transforming non-dependent call operator typesRichard Smith2014-11-201-0/+5
| | | | | | | | | | for lambda expressions. That can't ever work; we need to transform the parameters in order to create new ones in the new call operator context. Fixes a rejects-valid when transforming a context containing a lambda-expression that uses its function parameters in C++14 mode. llvm-svn: 222482
* Move test from r222476 to a better place; this was reduced to the point that itRichard Smith2014-11-201-0/+7
| | | | | | no longer contained a generic lambda. llvm-svn: 222477
* Don't allow lambdas to capture invalid decls during template instantiations.Richard Trieu2014-09-021-0/+50
| | | | | | Fixes PR20731. llvm-svn: 216936
* PR19249: Don't forget to DiagnoseUseOfDecl for the implicit use of a variableRichard Smith2014-03-251-0/+4
| | | | | | in a lambda capture. llvm-svn: 204757
* Temporary fix for PR18473: Don't try to evaluate the initializer for aRichard Smith2014-02-061-0/+15
| | | | | | | | | | | | type-dependent variable, even if the initializer isn't value-dependent. This happens for ParenListExprs composed of non-value-dependent subexpressions, for instance. We should really give ParenListExprs (and InitListExprs) the type of the initialized entity if they're used to represent a dependent initialization (and if so, set them to be type-, value- and instantiation-dependent). llvm-svn: 200954
* PR18128: a lambda capture-default is not permitted for a non-local lambdaRichard Smith2014-02-061-1/+21
| | | | | | expression. llvm-svn: 200948
* Fix regression in r197623: only diagnose a by-copy capture of an incompleteRichard Smith2014-01-211-0/+30
| | | | | | type if the capture is, actually, by copy. llvm-svn: 199772
* PR18477: Create a function scope representing the constructor call whenRichard Smith2014-01-171-1/+12
| | | | | | | | handling C++11 default initializers. Without this, other parts of Sema (such as lambda capture) would think the default initializer is part of the surrounding function scope. llvm-svn: 199453
* Fix computation of linkage within nested lambdas.Faisal Vali2013-10-011-0/+18
| | | | | | | | | | When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent). See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval. [On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions] llvm-svn: 191727
* Revert the linkage fix.Faisal Vali2013-09-291-18/+0
| | | | | | I got a bunch of buildbot failures that i don't understand - sorry. llvm-svn: 191647
* Fix computation of linkage within nested lambdas.Faisal Vali2013-09-291-0/+18
| | | | | | | | | | When nested lambdas are used in NSDMI's - this prevents infinite recursion. See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests. [On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions] llvm-svn: 191645
* Handle a difference in lambda return type deduction between C++11 and C++1y: ifRichard Smith2013-07-261-1/+15
| | | | | | | no return type is specified, C++11 will deduce a cv-qualified return type in some cases, but C++1y never will. llvm-svn: 187275
* PR16708: If a lambda has an implicit return type, don't get confused if its ↵Richard Smith2013-07-261-0/+8
| | | | | | return type has already been determined to be a type containing an 'auto'. llvm-svn: 187266
* Implement core issue 903: only integer literals with value 0 and prvalues ofRichard Smith2013-06-131-10/+13
| | | | | | type std::nullptr_t are null pointer constants from C++11 onwards. llvm-svn: 183883
* Sema: Don't emit a warning when __func__ is used in a lambda outside of a ↵Benjamin Kramer2012-12-061-0/+4
| | | | | | | | function. Fixes PR14518. llvm-svn: 169510
* Update regression tests for r166617.Eli Friedman2012-10-241-2/+2
| | | | llvm-svn: 166619
* DR1472: A reference isn't odr-used if it has preceding initialization,Richard Smith2012-10-201-5/+8
| | | | | | | | | 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. llvm-svn: 166361
* Handle lambdas where the lambda-declarator is an explicit "(void)". PR13854.Eli Friedman2012-09-201-0/+4
| | | | llvm-svn: 164274
* Add an extra check for invalid decls in the lambda semantic analysis to ↵Eli Friedman2012-09-181-0/+8
| | | | | | avoid a crash. PR13860. llvm-svn: 164168
* Implement warning for integral null pointer constants other than the literal 0.David Blaikie2012-08-081-3/+3
| | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 161501
* PR12057: Allow variadic template pack expansions to cross lambda boundaries.Richard Smith2012-07-251-0/+76
| | | | | | | | | | 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. llvm-svn: 160705
* Fixes some test cases that should have come along with r157943.Aaron Ballman2012-06-041-31/+28
| | | | llvm-svn: 157947
* Make the error about assigning to lambda-captured variablesJohn McCall2012-03-131-1/+1
| | | | | | clearer, and mention the existence of mutable lambdas. llvm-svn: 152598
* Alternate fix to PR12248: put Sema in charge of special-casingJohn McCall2012-03-131-0/+9
| | | | | | | | | 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. llvm-svn: 152593
* Make sure we treat variables captured by reference in lambda as modifiable ↵Eli Friedman2012-03-121-0/+6
| | | | | | lvalues. Regression from r152491. Fixes PR12248. llvm-svn: 152573
* Ensure that we instantiate static reference data members of class templatesRichard Smith2012-03-021-0/+7
| | | | | | | | | 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
* Remove FIXME: as Eli points out, the behavior here is now correct.Richard Smith2012-02-241-5/+3
| | | | llvm-svn: 151405
* When checking whether a reference to a variable is an ICE, look at the type ofRichard Smith2012-02-241-0/+27
| | | | | | | 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
* Only pop the expression evaluation context corresponding to a lambdaDouglas Gregor2012-02-211-0/+14
| | | | | | | | | 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
* Rewrite variable capture within lambda expressions and blocks,Douglas Gregor2012-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Within the body of a lambda expression, decltype((x)) for anDouglas Gregor2012-02-121-1/+2
| | | | | | | | | | | | | | | | 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
* Implement return type deduction for lambdas per C++11Douglas Gregor2012-02-091-6/+8
| | | | | | | | | [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
* Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor2012-02-091-38/+38
| | | | | | and rapidly becoming untrue. llvm-svn: 150165
* Various interrelated cleanups for lambdas:Douglas Gregor2012-02-091-1/+1
| | | | | | | | | | | | | | - 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
* Fix the result of VarDecl::checkInitIsICE so it is consistently accurate in ↵Eli Friedman2012-02-061-0/+3
| | | | | | C++11 mode. PR11928. llvm-svn: 149908
* Make explicit captures which cause implicit captures work correctly.Eli Friedman2012-02-031-2/+5
| | | | llvm-svn: 149719
* Implement implicit capture for lambda expressions.Eli Friedman2012-02-031-1/+37
| | | | | | 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
* Introduce the lambda scope before determining explicit captures, whichDouglas Gregor2012-02-011-4/+4
| | | | | | | | | | | | | 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
* Improve checking of explicit captures in a C++11 lambda expression:Douglas Gregor2012-02-011-27/+3
| | | | | | | | | | | | | | - 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
* Add an additional testcase for a lambda with implicit void return type.Eli Friedman2012-01-261-0/+1
| | | | llvm-svn: 149034
* Refactor to share code for handling return statements between lambda ↵Eli Friedman2012-01-261-0/+13
| | | | | | 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 ↵Eli Friedman2012-01-071-4/+21
| | | | | | 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
* Lambdas: semantic analysis of explicit captures.Eli Friedman2012-01-071-0/+37
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
OpenPOWER on IntegriCloud