summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/expr/expr.prim/expr.prim.lambda
Commit message (Collapse)AuthorAgeFilesLines
...
* Add compat/extension warnings for init captures.Richard Smith2013-09-282-2/+2
| | | | llvm-svn: 191609
* Per latest drafting, switch to implementing init-captures as if by declaringRichard Smith2013-09-282-33/+26
| | | | | | and capturing a variable declaration, and complete the implementation of them. llvm-svn: 191605
* Fix the test files by removing the unnecessary -emit-llvm flag (should ↵Faisal Vali2013-09-272-6/+2
| | | | | | address Matt Beaumont-Gay's concern regarding failure on a read-only filesystem) llvm-svn: 191531
* Implement a rudimentary form of generic lambdas.Faisal Vali2013-09-265-2/+268
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
* Revert "Implement a rudimentary form of generic lambdas."Manuel Klimek2013-08-225-267/+2
| | | | | | This reverts commit 606f5d7a99b11957e057e4cd1f55f931f66a42c7. llvm-svn: 189004
* Implement a rudimentary form of generic lambdas.Faisal Vali2013-08-225-2/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - nested lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware As an example of what compiles: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Augment AutoType's constructor (similar to how variadic template-type-parameters ala TemplateTypeParmDecl are implemented) to accept an IsParameterPack to encode a generic lambda parameter pack. - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that Sema::ActOnLambdaAutoParameter may use it to create the appropriate list of corresponding TemplateTypeParmDecl for each auto parameter identified within the generic lambda (also stored within the current LambdaScopeInfo). Additionally, a TemplateParameterList data-member was added to hold the invented TemplateParameterList AST node which will be much more useful once we teach TreeTransform how to transform generic lambdas. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - Teach Sema::ActOnStartOfLambdaDefinition to set the return type of a lambda without a trailing return type to 'auto' in C++1y mode, and teach the return type deduction machinery in SemaStmt.cpp to process either C++11 and C++14 lambda's correctly depending on the flag. - various tests were added - but much more will be needed. A greatful thanks to all reviewers including Eli Friedman, James Dennett and the ever illuminating Richard Smith. And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 188977
* sizeof(void) etc. should be a hard error in C++.Eli Friedman2013-08-131-1/+1
| | | | | | PR16872. llvm-svn: 188324
* Handle a difference in lambda return type deduction between C++11 and C++1y: ifRichard Smith2013-07-261-1/+4
| | | | | | | 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
* More fixes for block mangling.Eli Friedman2013-07-021-1/+1
| | | | | | | | | | | | Make sure we properly treat names defined inside a block as local names. There are basically three fixes here. One, correctly treat blocks as a context where we need to use local-name mangling using the new isLocalContainerContext helper. Two, make CXXNameMangler::manglePrefix handle local names in a consistent way. Three, extend CXXNameMangler::mangleLocalName so it can mangle a block correctly. llvm-svn: 185450
* Don't skip lambdas when mangling local vars.Eli Friedman2013-07-021-1/+1
| | | | | | | | This commit rearranges the logic in CXXNameMangler::mangleLocalName and GetLocalClassDecl so that it doesn't accidentally skip over lambdas. It also reduces code duplication a bit. llvm-svn: 185402
* Fix mangling for block literals.Eli Friedman2013-07-011-1/+1
| | | | | | | | | | | | | | | Blocks, like lambdas, can be written in contexts which are required to be treated as the same under ODR. Unlike lambdas, it isn't possible to actually take the address of a block, so the mangling of the block itself doesn't matter. However, objects like static variables inside a block do need to be mangled in a consistent way. There are basically three components here. One, block literals need a consistent numbering. Two, objects/types inside a block literal need to be mangled using it. Three, objects/types inside a block literal need to have their linkage computed correctly. llvm-svn: 185372
* Change mangling of objects inside block literals.Eli Friedman2013-06-241-1/+1
| | | | | | | | | | | | This changes the mangling of local static variables/etc. inside blocks to do something simple and sane. This avoids depending on the way we mangle blocks, which isn't really appropriate here. John, please take a look at this to make sure the mangling I chose is sane. Fixes <rdar://problem/14074423>. llvm-svn: 184780
* PR16263: Implement current direction of core issue 1376. Binding a reference toRichard Smith2013-06-151-1/+1
| | | | | | | | | | | the result of a cast-to-reference-type lifetime-extends the object to which the reference inside the cast binds. This requires us to look for subobject adjustments on both the inside and the outside of the MaterializeTemporaryExpr when looking for a temporary to lifetime-extend (which we also need for core issue 616, and possibly 1213). llvm-svn: 184024
* Unify return type checking for functions and ObjC methods. Move all theEli Friedman2013-06-141-1/+1
| | | | | | | | random checks for ObjC object return types to SemaType.cpp. Fixes issue with ObjC method type checking reported on cfe-dev. llvm-svn: 184006
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-163-0/+110
| | | | | | | | | | | | | a FieldDecl from it, and propagate both into the closure type and the LambdaExpr. You can't do much useful with them yet -- you can't use them within the body of the lambda, because we don't have a representation for "the this of the lambda, not the this of the enclosing context". We also don't have support or a representation for a nested capture of an init-capture yet, which was intended to work despite not being allowed by the current standard wording. llvm-svn: 181985
* C++1y: provide full 'auto' return type deduction for lambda expressions. ThisRichard Smith2013-05-122-0/+10
| | | | | | completes the implementation of N3638. llvm-svn: 181669
* DR974: Lambdas can have default arguments.Richard Smith2013-04-172-6/+4
| | | | llvm-svn: 179688
* Implement C++11 semantics for [[noreturn]] attribute. This required splittingRichard Smith2013-01-172-3/+5
| | | | | | | | it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as affecting the function type, whereas [[noreturn]] does not). llvm-svn: 172691
* Improve diagnostic wording for when an implicitly-deleted special memberRichard Smith2012-12-281-1/+1
| | | | | | function is selected by overload resolution. llvm-svn: 171190
* When capturing 'this' in a lambda, make sure to update the set ofDouglas Gregor2012-10-251-0/+15
| | | | | | | array-index starting values for the 'this' capture. Fixes <rdar://problem/12426831>. llvm-svn: 166709
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-194-0/+4
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* PR12057: Allow variadic template pack expansions to cross lambda boundaries.Richard Smith2012-07-252-3/+20
| | | | | | | | | | 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
* block literal irgen: several improvements on naming blockFariborz Jahanian2012-06-261-3/+3
| | | | | | | | | | | | literal helper functions. All helper functions (global and locals) use block_invoke as their prefix. Local literal helper names are prefixed by their enclosing mangled function names. Blocks in non-local initializers (e.g. a global variable or a C++11 field) are prefixed by their mangled variable name. The descriminator number added to end of the name starts off with blank (for first block) and _<N> (for the N+2-th block). llvm-svn: 159206
* Check the parameter lists and return type of both blocks and lambdasDouglas Gregor2012-06-151-0/+21
| | | | | | | for unexpanded parameter packs. Fixes the crash-on-invalid in PR13117. llvm-svn: 158525
* Fixes some test cases that should have come along with r157943.Aaron Ballman2012-06-041-4/+4
| | | | llvm-svn: 157947
* Clean up r156925, so that we only mark the capturing DeclRefExpr of aDouglas Gregor2012-05-162-22/+29
| | | | | | | | | lambda as referring to a local in an enclosing scope if we're in the enclosing scope of the lambda (not it's function call operator). Also, turn the test into an IR generation test, since that's where the crashes occurred. Really fixes PR12746 / <rdar://problem/11465120>. llvm-svn: 156926
* Fix code generation of variables reference expressions when mixingDouglas Gregor2012-05-161-0/+22
| | | | | | | blocks and lambdas, based heavily on a patch from Meador Inge. Fixes PR12746 / <rdar://problem/11465120>. llvm-svn: 156925
* Improve diagnostics for invalid use of non-static members / this:Richard Smith2012-04-051-1/+1
| | | | | | | | | | | | * s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted the former by 28-2 in our diagnostics. * Fix the "use of member in static member function" diagnostic to correctly detect this situation inside a block or lambda. * Produce a more specific "invalid use of non-static member" diagnostic for the case where a nested class member refers to a member of a lexically-surrounding class. llvm-svn: 154073
* Make the odr-use logic work correctly for constant-expressions. PR12006.Eli Friedman2012-02-291-3/+2
| | | | llvm-svn: 151699
* Teach overload resolution to prefer user-defined conversion via aDouglas Gregor2012-02-221-0/+31
| | | | | | | | | | lambda closure type's function pointer conversion over user-defined conversion via a lambda closure type's block pointer conversion, always. This is a preference for more-standard code (since blocks are an extension) and a nod to efficiency, since function pointers don't require any memory management. Fixes PR12063. llvm-svn: 151170
* Generate an AST for the conversion from a lambda closure type to aDouglas Gregor2012-02-221-0/+0
| | | | | | | | | | | | | | | block pointer that returns a block literal which captures (by copy) the lambda closure itself. Some aspects of the block literal are left unspecified, namely the capture variable (which doesn't actually exist) and the body (which will be filled in by IRgen because it can't be written as an AST). Because we're switching to this model, this patch also eliminates tracking the copy-initialization expression for the block capture of the conversion function, since that information is now embedded in the synthesized block literal. -1 side tables FTW. llvm-svn: 151131
* Improve our handling of lambda expressions that occur within defaultDouglas Gregor2012-02-211-0/+6
| | | | | | | | | | | | | | | | | | | arguments. There are two aspects to this: - Make sure that when marking the declarations referenced in a default argument, we don't try to mark local variables, both because it's a waste of time and because the semantics are wrong: we're not in a place where we could capture these variables again even if it did make sense. - When a lambda expression occurs in a default argument of a function template, make sure that the corresponding closure type is considered dependent, so that it will get properly instantiated. The second bit is a bit of a hack; to fix it properly, we may have to rearchitect our handling of default arguments, parsing them only after creating the function definition. However, I'd like to separate that work from the lambdas work. llvm-svn: 151076
* Rewrite variable capture within lambda expressions and blocks,Douglas Gregor2012-02-183-5/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Unify our computation of the type of a captured reference to aDouglas Gregor2012-02-182-2/+5
| | | | | | | variable; it was previously duplicated, and one of the copies failed to account for outer non-mutable lambda captures. llvm-svn: 150872
* Only add 'const' to the type of variables captured in a lambda whenDouglas Gregor2012-02-171-0/+4
| | | | | | we're capturing it by value in a non-mutable lambda. llvm-svn: 150791
* Lambda closure types are always considered to be like "local" classes,Douglas Gregor2012-02-161-0/+33
| | | | | | | | | even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
* Implicitly define a lambda's conversion functions (to functionDouglas Gregor2012-02-161-0/+20
| | | | | | | | | | | | | pointers and block pointers). We use dummy definitions to keep the invariant that an implicit, used definition has a body; IR generation will substitute the actual contents, since they can't be represented as C++. For the block pointer case, compute the copy-initialization needed to capture the lambda object in the block, which IR generation will need later. llvm-svn: 150645
* Lambda closure types have a conversion function to a block pointerDouglas Gregor2012-02-151-0/+7
| | | | | | | | | | | with the same parameter types and return type as the function call operator. This is the real answer to http://stackoverflow.com/questions/4148242/is-it-possible-to-convert-a-c0x-lambda-to-a-clang-block :) llvm-svn: 150620
* When overload resolution picks an implicitly-deleted special memberDouglas Gregor2012-02-151-6/+3
| | | | | | | | | function, provide a specialized diagnostic that indicates the kind of special member function (default constructor, copy assignment operator, etc.) and that it was implicitly deleted. Add a hook where we can provide more detailed information later. llvm-svn: 150611
* A little more lambda capture initialization diagnostics cleanupDouglas Gregor2012-02-151-1/+8
| | | | llvm-svn: 150589
* Introduce a new initialization entity for lambda captures, andDouglas Gregor2012-02-151-3/+6
| | | | | | specialize location information and diagnostics for this entity. llvm-svn: 150588
* Specialize noreturn diagnostics for lambda expressions.Douglas Gregor2012-02-153-3/+5
| | | | llvm-svn: 150586
* Specialize the diagnostic complaining about conflicting types ofDouglas Gregor2012-02-151-2/+2
| | | | | | | return statements within a lambda; this diagnostic previously referred to blocks. llvm-svn: 150584
* Implement C++ core issue 974, which permits default arguments forDouglas Gregor2012-02-142-2/+53
| | | | | | | | lambda expressions. Because these issue was pulled back from Ready status at the Kona meeting, we still emit an ExtWarn when using default arguments for lambda expressions. llvm-svn: 150519
* Check the return type of lambda expressions.Douglas Gregor2012-02-142-0/+16
| | | | llvm-svn: 150503
* Implement support for lambda capture pack expansions, e.g.,Douglas Gregor2012-02-141-0/+58
| | | | | | [&values...] { print(values...); } llvm-svn: 150497
* Simple test ensuring that we perform direct initialization when ↵Douglas Gregor2012-02-141-0/+9
| | | | | | copy-capturing in lambdas llvm-svn: 150442
* Link together the call operator produced from transforming a lambdaDouglas Gregor2012-02-141-0/+71
| | | | | | | | expression with the original call operator, so that we don't try to separately instantiate the call operator. Test and tweak a few more bits for template instantiation of lambda expressions. llvm-svn: 150440
* Introduce support for template instantiation of lambdaDouglas Gregor2012-02-131-0/+45
| | | | | | | | | | | | | | | | | | expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
* Within the body of a lambda expression, decltype((x)) for anDouglas Gregor2012-02-122-2/+43
| | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud