summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/expr/expr.prim/expr.prim.lambda
Commit message (Collapse)AuthorAgeFilesLines
* [Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3)Faisal Vali2016-03-211-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement lambda capture of *this by copy. For e.g.: struct A { int d = 10; auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; } }; auto L = A{}.foo(); // A{}'s lifetime is gone. // Below is still ok, because *this was captured by value. assert(L(10) == 20); assert(L(100) == 120); If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined. Implementation Strategy: - amend the parser to accept *this in the lambda introducer - add a new king of capture LCK_StarThis - teach Sema::CheckCXXThisCapture to handle by copy captures of the enclosing object (i.e. *this) - when CheckCXXThisCapture does capture by copy, the corresponding initializer expression for the closure's data member direct-initializes it thus making a copy of '*this'. - in codegen, when assigning to CXXThisValue, if *this was captured by copy, make sure it points to the corresponding field member, and not, unlike when captured by reference, what the field member points to. - mark feature as implemented in svn Much gratitude to Richard Smith for his carefully illuminating reviews! llvm-svn: 263921
* N3922: direct-list-initialization of an auto-typed variable no longer deduces aRichard Smith2015-11-111-2/+3
| | | | | | | | | | | | | | | | | | | std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
* Clarify the error message when the reason the conversion is not viable is ↵Nick Lewycky2015-08-251-1/+1
| | | | | | because the returned value does not match the function return type. llvm-svn: 245979
* Instantiate function declarations in instantiated functions.Serge Pavlov2015-08-231-5/+8
| | | | | | | | | | | | | | | | | If a function declaration is found inside a template function as in: template<class T> void f() { void g(int x = T::v) except(T::w); } it must be instantiated along with the enclosing template function, including default arguments and exception specification. Together with the patch committed in r240974 this implements DR1484. Differential Revision: http://reviews.llvm.org/D11194 llvm-svn: 245810
* Fix typo from r237482. "to reference of type" --> "to reference to type"Richard Trieu2015-05-161-4/+4
| | | | llvm-svn: 237507
* When emitting a dropped qualifier error, show which qualifiers are dropped.Richard Trieu2015-05-161-4/+4
| | | | llvm-svn: 237505
* Reverse the order of types in the reference dropping qualifiers error.Richard Trieu2015-05-151-4/+4
| | | | | | | | The error has the form ... 'int' ... 'const int' ... dropped qualifiers. At first glance, it appears that the const qualifier is added. Reverse the types so that the second type is less qualified than the first. llvm-svn: 237482
* PR23334: Perform semantic checking of lambda capture initialization in the ↵Richard Smith2015-04-272-6/+6
| | | | | | | | | | | | | | | | | | right context. Previously we'd try to perform checks on the captures from the middle of parsing the lambda's body, at the point where we detected that a variable needed to be captured. This was wrong in a number of subtle ways. In PR23334, we couldn't correctly handle the list of potential odr-uses resulting from the capture, and our attempt to recover from that resulted in a use-after-free. We now defer building the initialization expression until we leave the lambda body and return to the enclosing context, where the initialization does the right thing. This patch only covers lambda-expressions, but we should apply the same change to blocks and captured statements too. llvm-svn: 235921
* Add a warning for direct-list-initialization of a variable with a deduced typeRichard Smith2015-02-111-2/+2
| | | | | | | | (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we implement N3922, so we intend to warn on this in Clang 3.6 then change the semantics in Clang 3.7. llvm-svn: 228792
* DR1048: drop top-level cv-qualifiers when deducing the return type of aRichard Smith2014-12-191-5/+2
| | | | | | lambda-expression in C++11, to match the C++14 rules. llvm-svn: 224620
* Adding a -Wunused-value warning for expressions with side effects used in an ↵Aaron Ballman2014-12-172-2/+2
| | | | | | unevaluated expression context, such as sizeof(), or decltype(). Also adds a similar warning when the expression passed to typeid() *is* evaluated, since it is equally likely that the user would expect the expression operand to be unevaluated in that case. llvm-svn: 224465
* DR1891, PR21787: a lambda closure type has no default constructor, rather thanRichard Smith2014-12-102-5/+5
| | | | | | having a deleted default constructor. llvm-svn: 223953
* Handle use of default member initializers before end of outermost classReid Kleckner2014-11-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, when we have this situation: struct A { template <typename T> struct B { int m1 = sizeof(A); }; B<int> m2; }; We can't parse m1's initializer eagerly because we need A to be complete. Therefore we wait until the end of A's class scope to parse it. However, we can trigger instantiation of B before the end of A, which will attempt to instantiate the field decls eagerly, and it would build a bad field decl instantiation that said it had an initializer but actually lacked one. Fixed by deferring instantiation of default member initializers until they are needed during constructor analysis. This addresses a long standing FIXME in the code. Fixes PR19195. Reviewed By: rsmith Differential Revision: http://reviews.llvm.org/D5690 llvm-svn: 222192
* PR21180: Lambda closure types are neither aggregates nor literal types.Richard Smith2014-10-071-0/+5
| | | | llvm-svn: 219222
* More fixes for isBetterOverloadCandidate not being a strict weak ordering. TheRichard Smith2014-05-171-0/+18
| | | | | | bug was obvious from inspection, figuring out a way to test it was... less so. llvm-svn: 209060
* Render anonymous entities as '(anonymous <thing>)' (and lambdas as '(lambda ↵David Blaikie2014-04-021-1/+1
| | | | | | | | | | | | at ... )') For namespaces, this is consistent with mangling and GCC's debug info behavior. For structs, GCC uses <anonymous struct> but we prefer consistency between all anonymous entities but don't want to confuse them with template arguments, etc, so we'll just go with parens in all cases. llvm-svn: 205398
* Normalize line endingsDavid Majnemer2014-03-022-156/+156
| | | | | | | Some files had CRLF line terminators, some only had a mixture of CRLF and LF. Switch to LF. llvm-svn: 202659
* Require the type of a by-copy capture to be complete before creating its field.Douglas Gregor2013-12-181-0/+9
| | | | | | | | | | | | The problem here is more serious than the fix implies. Adding a field to a class updates the triviality bits for the class (among other things). Failing to require a complete type before adding the field meant that these updates don't happen in the well-formed case where the capture is an uninstantiated class template specialization, leading the lambda itself to be treated as having a trivial copy constructor when it shouldn't. Fixes <rdar://problem/15560464>. llvm-svn: 197623
* Switch to the new MingW ABI.Rafael Espindola2013-12-121-1/+1
| | | | | | | GCC 4.7 changed the MingW ABI. On the clang side this means that methods now have the thiscall calling convention by default. llvm-svn: 197164
* Delete the now unnecessary test/generic-lambda-unimplemented-1y.cppFaisal Vali2013-12-071-31/+0
| | | | llvm-svn: 196664
* This patch implements capturing of variables within generic lambdas.Faisal Vali2013-11-073-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks. What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing. As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable. Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda. Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming. This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being: - generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ... - nested variadic expansions such as: auto K = [](auto ... OuterArgs) { vp([=](auto ... Is) { decltype(OuterArgs) OA = OuterArgs; return 0; }(5)...); return 0; }; auto M = K('a', ' ', 1, " -- ", 3.14); currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard. A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless! Now let's hope this commit doesn't upset the buildbot gods ;) Thanks! llvm-svn: 194188
* And Again: Teach TreeTransform how to transform nested generic lambdas.Faisal Vali2013-10-231-17/+0
| | | | | | | | | | | | | | | | | | | | | | | | A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted, The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off. Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476. The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created. Another attempt caused a test to fail (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091533.html) and also had to be reverted - my apologies - in my haste, i did not run all the tests - argh! Now all the tests seem to pass - but a Fixme has been added - since I suspect Richard will find the fix a little inelegant ;) I shall try and work on a more elegant fix once I have had a chance to discuss with Richard or Doug at a later date. Hopefully the third time;s a charm *fingers crossed* This does not yet include capturing. Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 193230
* Revert r193223 and r193216.Rafael Espindola2013-10-231-0/+17
| | | | | | | | | | They were causing CodeGenCXX/mangle-exprs.cpp to fail. Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl." Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves." llvm-svn: 193226
* Again: Teach TreeTransform and family how to transform generic Faisal Vali2013-10-231-17/+0
| | | | | | | | | | | | | | | | | | | | | lambdas nested within templates and themselves. A previous attempt http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090049.html resulted in PR 17476, and was reverted, The original TransformLambdaExpr (pre generic-lambdas) transformed the TypeSourceInfo of the Call operator in its own instantiation scope via TransformType. This resulted in the parameters of the call operator being mapped to their transformed counterparts in an instantiation scope that would get popped off. Then a call to TransformFunctionParameters would add the parameters and their transformed mappings (but newly created ones!) to the current instantiation scope. This would result in a disconnect between the new call operator's TSI parameters and those used to construct the call operator declaration. This was ok in the non-generic lambda world - but would cause issues with nested transformations (when non-generic and generics were interleaved) in the generic lambda world - that I somewhat kludged around initially - but this resulted in PR17476. The new approach seems cleaner. We only do the transformation of the TypeSourceInfo - but we make sure to do it in the current instantiation scope so we don't lose the untransformed to transformed mappings of the ParmVarDecls when they get created. This does not yet include capturing. Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 193216
* Diagnose by-copy captures of abstract classes.Douglas Gregor2013-10-111-0/+12
| | | | | | Fixes <rdar://problem/14468891>. llvm-svn: 192419
* Revert "Teach TreeTransform and family how to transform generic lambdas ↵Rafael Espindola2013-10-041-0/+17
| | | | | | | | within templates and nested within themselves." This reverts commit r191879. It caused llvm.org/pr17476. llvm-svn: 191955
* Teach TreeTransform and family how to transform generic lambdas within ↵Faisal Vali2013-10-031-17/+0
| | | | | | | | | | | | | | | | | templates and nested within themselves. This does not yet include capturing (that is next). Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090048.html When I first committed this patch - a bunch of buildbots were unable to compile the code that VS2010 seemed to compile. Seems like there was a dependency on Sema/Template.h which VS did not seem to need, but I have now added for the other compilers. It still compiles on Visual Studio 2010 - lets hope the buildbots remain quiet (please!) llvm-svn: 191879
* Revert changes from the nested lambdas commit till i figure out Faisal Vali2013-10-031-0/+17
| | | | | | why the buildbots are failing. llvm-svn: 191876
* Teach TreeTransform and family how to transform generic lambdas within ↵Faisal Vali2013-10-031-17/+0
| | | | | | | | | | | | | | templates and nested within themselves. This does not yet include capturing (that is next). Please see test file for examples. This patch was LGTM'd by Doug: http://llvm-reviews.chandlerc.com/D1784 llvm-svn: 191875
* Implement conversion to function pointer for generic lambdas without captures.Faisal Vali2013-09-291-23/+20
| | | | | | | | | | | | | | | | The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator. This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM. A few minor changes: - per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation). - I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively. - Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming. Thanks! llvm-svn: 191634
* 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
OpenPOWER on IntegriCloud