summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/lambda-expressions.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix crash-on-invalid-code in lambda constant evaluation.James Y Knight2019-12-041-5/+12
| | | | | | | | | | If the lambda used 'this' without without capturing it, an error was emitted, but the constant evaluator would still attempt to lookup the capture, and failing to find it, dereference a null pointer. This only happens in C++17 (as that's when lambdas were made potentially-constexpr). Therefore, I also updated the lambda-expressions.cpp test to run in both C++14 and C++17 modes.
* PR43242: Fix crash when typo-correcting to an operator() that should notRichard Smith2019-09-091-0/+4
| | | | | | have been visible. llvm-svn: 371468
* Defer building 'this' captures until we have left the capturing regionRichard Smith2019-05-311-2/+4
| | | | | | | | | | and returned to the context in which 'this' should be captured. This means we now always mark 'this' referenced from the context in which it's actually referenced, rather than potentially from some context nested within that. llvm-svn: 362182
* If capturing a variable fails, add a capture anyway (and mark itRichard Smith2019-05-281-2/+2
| | | | | | invalid) so that we can avoid repeated diagnostics for the same capture. llvm-svn: 361891
* Diagnose non-dependent qualified friend function template declarationsRichard Smith2019-05-021-8/+13
| | | | | | | that don't match any existing declaration. Don't get confused and treat such declarations as template *specializations*. llvm-svn: 359746
* Fix crash on invalid.Richard Trieu2018-02-061-0/+15
| | | | | | Don't call a method when the pointer is null. llvm-svn: 324308
* Fix and simplify handling of return type for (generic) lambda conversion ↵Richard Smith2018-01-021-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | function to function pointer. Previously, we would: * compute the type of the conversion function and static invoker as a side-effect of template argument deduction for a conversion * re-compute the type as part of deduced return type deduction when building the conversion function itself Neither of these turns out to be quite correct. There are other ways to reach a declaration of the conversion function than in a conversion (such as an explicit call or friend declaration), and performing auto deduction causes the function type to be rebuilt in the context of the lambda closure type (which is different from the context in which it originally appeared, resulting in spurious substitution failures for constructs that are valid in one context but not the other, such as the use of an enclosing class's "this" pointer). This patch switches us to use a different strategy: as before, we use the declared type of the operator() to form the type of the conversion function and invoker, but we now populate that type as part of return type deduction for the conversion function. And the invoker is now treated as simply being an implementation detail of building the conversion function, and isn't given special treatment by template argument deduction for the conversion function any more. llvm-svn: 321683
* Fix PR25627: constant expressions being odr-used in template arguments.Faisal Vali2017-05-201-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch ensures that clang processes the expression-nodes that are generated when disambiguating between types and expressions within template arguments as constant-expressions by installing the ConstantEvaluated ExpressionEvaluationContext just before attempting the disambiguation - and then making sure that Context carries through into ParseConstantExpression (by refactoring it out into a function that does not create its own EvaluationContext: ParseConstantExpressionInExprEvalContext) Note, prior to this patch, trunk would correctly disambiguate and identify the expression as an expression - and while it would annotate the token with the expression - it would fail to complete the odr-use processing (specifically, failing to trigger Sema::UpdateMarkingForLValueToRValue as is done for all Constant Expressions, which would remove it from being considered odr-used). By installing the ConstantExpression Evaluation Context prior to disambiguation, and making sure it carries though, we ensure correct processing of the expression-node. For e.g: template<int> struct X { }; void f() { const int N = 10; X<N> x; // should be OK. [] { return X<N>{}; }; // Should be OK - no capture - but clang errors! } See a related bug: https://bugs.llvm.org//show_bug.cgi?id=25627 In summary (and reiteration), the fix is as follows: - Remove the EnteredConstantEvaluatedContext action from ParseTemplateArgumentList (relying on ParseTemplateArgument getting it right) - Add the EnteredConstantEvaluatedContext action just prior to undergoing the disambiguating parse, and if the parse succeeds for an expression, carry the context though into a refactored version of ParseConstantExpression that does not create its own ExpressionEvaluationContext. See https://reviews.llvm.org/D31588 for additional context regarding some of the more fragile and complicated approaches attempted, and Richard's feedback that eventually shaped the simpler and more robust rendition that is being committed. Thanks Richard! llvm-svn: 303492
* [Parser] Correct typo after lambda capture initializer is parsed.Akira Hatanaka2016-12-201-0/+15
| | | | | | | | | | | | | | | | This patch fixes an assertion that is triggered when RecordLayoutBuilder tries to compute the size of a field (for capture "name" in the test case) whose type hasn't been deduced. The patch fixes the bug by correcting the typo of the capture initializer after the initializer is parsed and before setting the expression for the annotation token. Fixes PR30566. rdar://problem/23380132 Differential Revision: https://reviews.llvm.org/D25206 llvm-svn: 290156
* PR23281: Fix implementation of DR1891 to implement the intent: that is, aRichard Smith2016-11-161-0/+33
| | | | | | lambda-expression does not have a move-assignment operator. llvm-svn: 287057
* [Sema] Teach getCurrentThisType to reconize lambda in in-class initializerErik Pilkington2016-07-271-2/+28
| | | | | | | | Fixes PR27994, a crash on valid. Differential revision: https://reviews.llvm.org/D21145 llvm-svn: 276900
* Add null check to diagnostic path for lambda captures.Richard Trieu2016-03-051-0/+12
| | | | | | | | Previously, the failed capture of a variable in nested lambdas may crash when the lambda pointer is null. Only give the note if a location can be retreived from the lambda pointer. llvm-svn: 262765
* [SemaCXX] Fix crash-on-invalid while trying to deduce return type of a lambda.Argyrios Kyrtzidis2016-01-301-0/+11
| | | | | | rdar://22032373 llvm-svn: 259287
* 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
OpenPOWER on IntegriCloud