summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaLambda.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* ArrayRef-ize TemplateParameterList. NFCDavid Majnemer2015-12-271-3/+4
| | | | llvm-svn: 256463
* Add the `pass_object_size` attribute to clang.George Burgess IV2015-12-021-0/+6
| | | | | | | | | | | | | `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
* N3922: direct-list-initialization of an auto-typed variable no longer deduces aRichard Smith2015-11-111-58/+38
| | | | | | | | | | | | | | | | | | | 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
* Perform Objective-C lifetime adjustments before comparing deduced lambda ↵Douglas Gregor2015-10-011-1/+2
| | | | | | | | | | result types. Objective-C ARC lifetime qualifiers are dropped when canonicalizing function types. Perform the same adjustment before comparing the deduced result types of lambdas. Fixes rdar://problem/22344904. llvm-svn: 249065
* [AST] ArrayRefize BlockDecl::setCaptures. No functionality change intended.Benjamin Kramer2015-08-051-2/+1
| | | | llvm-svn: 244027
* Fix assertion failure if a lambda array-capture is followed by a this capture.Richard Smith2015-04-281-3/+4
| | | | llvm-svn: 236043
* Silencing a -Wuninitialized warning in a different way. This replaces ↵Aaron Ballman2015-04-281-22/+19
| | | | | | r235981, but is still NFC. llvm-svn: 236002
* Silencing a spurious -Wuninitialized warning with this local; NFC.Aaron Ballman2015-04-281-1/+1
| | | | llvm-svn: 235981
* PR23334: Perform semantic checking of lambda capture initialization in the ↵Richard Smith2015-04-271-57/+130
| | | | | | | | | | | | | | | | | | 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
* Re-land "MS ABI: lambda call operators are instance methods and should use ↵Reid Kleckner2015-04-011-15/+20
| | | | | | | | | | | | | thiscall" Update the test cases to pass when lambda call operators use thiscall. Update the lambda-to-block conversion operator to use the default free function calling convention instead of the call operator's convention. This reverts commit r233082 and re-instates r233023. llvm-svn: 233835
* DR1048: drop top-level cv-qualifiers when deducing the return type of aRichard Smith2014-12-191-2/+7
| | | | | | lambda-expression in C++11, to match the C++14 rules. llvm-svn: 224620
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-1/+1
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* Pass around CorrectionCandidateCallbacks as unique_ptrs soKaelyn Takata2014-10-271-2/+2
| | | | | | TypoCorrectionConsumer can keep the callback around as long as needed. llvm-svn: 220693
* [C++11] Support for capturing of variable length arrays in lambda expression.Alexey Bataev2014-08-281-0/+6
| | | | | | Differential Revision: http://reviews.llvm.org/D4368 llvm-svn: 216649
* C++1y is now C++14!Aaron Ballman2014-08-191-3/+3
| | | | | | Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording. llvm-svn: 215982
* Refactoring. Remove release and take methods from ActionResult. Rename ↵Nikola Smiljanic2014-05-291-5/+5
| | | | | | takeAs to getAs. llvm-svn: 209800
* [C++11] Use 'nullptr'. Sema edition.Craig Topper2014-05-261-26/+27
| | | | llvm-svn: 209613
* Consolidate single void paramter checkingAlp Toker2014-05-111-4/+1
| | | | | | | | Also correct argument/parameter terminology. No change in functionality. llvm-svn: 208498
* Decouple ExprCXX.h and DeclCXX.h and clean up includes a bit.Benjamin Kramer2014-05-101-10/+6
| | | | | | | Required pulling LambdaExpr::Capture into its own header. No functionality change. llvm-svn: 208470
* Fix a bunch of mislayered clang/Lex includes from SemaAlp Toker2014-05-031-15/+13
| | | | llvm-svn: 207896
* [Sema] Adjust Sema::getCurBlock()/getCurLambda() to take into account that ↵Argyrios Kyrtzidis2014-04-261-1/+2
| | | | | | | | | | | we may have switch CurContext due to class template instantiation. Fixes crash of the included test case. rdar://16527205 llvm-svn: 207325
* PR19249: Don't forget to DiagnoseUseOfDecl for the implicit use of a variableRichard Smith2014-03-251-0/+2
| | | | | | in a lambda capture. llvm-svn: 204757
* DR1346: a parenthesized braced-init-list cannot be used as the initializer whenRichard Smith2014-03-121-0/+3
| | | | | | performing auto type deduction. llvm-svn: 203683
* Reverting llvm::distance changes to use std::distance with iterators ↵Aaron Ballman2014-03-101-4/+2
| | | | | | | | instead, per post-commit review feedback. Replacing llvm::copy changes with SmallVector range-based construction which is a considerably cleaner approach. llvm-svn: 203461
* [C++11] Replacing RecordDecl iterators field_begin() and field_end() with ↵Aaron Ballman2014-03-081-10/+6
| | | | | | iterator_range fields(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203355
* [C++11] Replacing ObjCMethodDecl iterators param_begin() and param_end() ↵Aaron Ballman2014-03-071-4/+2
| | | | | | with iterator_range params(). Updating all of the usages of the iterators with range-based for loops. llvm-svn: 203255
* argument -> parameter terminology fixes for FunctionTypeInfoAlp Toker2014-02-261-5/+5
| | | | | | This is a continuation of r199686. llvm-svn: 202307
* Implement DR577David Majnemer2014-02-191-1/+0
| | | | | | | | DR18 previously forebode typedefs to be used as parameter types if they were of type 'void'. DR577 allows 'void' to be used as a function parameter type regardless from where it came. llvm-svn: 201631
* PR18128: a lambda capture-default is not permitted for a non-local lambdaRichard Smith2014-02-061-1/+18
| | | | | | expression. llvm-svn: 200948
* Rename getResultLoc() tooAlp Toker2014-01-251-1/+1
| | | | | | | | Follow up to r200082. Spotted by Dmitri llvm-svn: 200105
* Rename getResultType() on function and method declarations to getReturnType()Alp Toker2014-01-251-5/+5
| | | | | | | | | | | | | | | A return type is the declared or deduced part of the function type specified in the declaration. A result type is the (potentially adjusted) type of the value of an expression that calls the function. Rule of thumb: * Declarations have return types and parameters. * Expressions have result types and arguments. llvm-svn: 200082
* Update FunctionTypeLoc and related names to match r199686Alp Toker2014-01-211-2/+2
| | | | llvm-svn: 199699
* Rename FunctionProtoType accessors from 'arguments' to 'parameters'Alp Toker2014-01-201-5/+6
| | | | | | | | | | | | | | | | | Fix a perennial source of confusion in the clang type system: Declarations and function prototypes have parameters to which arguments are supplied, so calling these 'arguments' was a stretch even in C mode, let alone C++ where default arguments, templates and overloading make the distinction important to get right. Readability win across the board, especially in the casting, ADL and overloading implementations which make a lot more sense at a glance now. Will keep an eye on the builders and update dependent projects shortly. No functional change. llvm-svn: 199686
* Sort all the #include lines with LLVM's utils/sort_includes.py whichChandler Carruth2014-01-071-1/+1
| | | | | | | encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
* Rename a variable that I missed in the previous refactoring.Faisal Vali2013-12-091-4/+4
| | | | llvm-svn: 196740
* Fix the message to go along with the assertion that was just fixed.Faisal Vali2013-12-081-1/+1
| | | | | | argh! llvm-svn: 196722
* Fix an assertion introduced by my previous refactoring.Faisal Vali2013-12-081-6/+4
| | | | | | Add back the test that was triggering the assertion (which I removed mistakenly thinking it was triggering just a warning and not an assertion). My error was brought to my attention by Rafael (Thanks!). llvm-svn: 196721
* [REFACTOR] Refactored some of the generic-lambda capturing code.Faisal Vali2013-12-071-93/+182
| | | | | | | | | | | | | | | Employed the following refactorings: - Renamed some functions - Introduced explaining variables - Cleaned up & added comments - Used Optional<unsigned> for return value instead of an out parameter - Added assertions - Constified a few member functions No functionality change. All regressions pass. llvm-svn: 196662
* Fix init-captures for generic lambdas.Faisal Vali2013-12-051-19/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
* This patch implements capturing of variables within generic lambdas.Faisal Vali2013-11-071-9/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Sema: Improve comment introduced in r193397David Majnemer2013-11-051-0/+5
| | | | llvm-svn: 194052
* Sema: Do not allow lambda expressions to appear inside of constant expressionsDavid Majnemer2013-10-251-4/+9
| | | | | | | | | We would previously not diagnose this which would lead to crashes (on very strange code). This fixes PR17675. llvm-svn: 193397
* Fix an instantiation bug with nested generic lambdas and conversion to fptrs.Faisal Vali2013-10-241-41/+107
| | | | | | | | | | | | | | | | | This patch fixes the typelocs of the conversion-operator and the conversion-operator-name and adds the parameters of the call operator to the FunctionProtoTypeLoc of the respective entities. Thus, when the template declarations (conversion operators) undergo deduction and instantiation/transformation/substitution - they add themselves to the local instantiation scope if needed. This patch supports the following: auto L = [](auto b) { return [](auto a) ->decltype(a) { return a; }; }; int (*fp)(int) = L(8); Richard LGTM'd this patch: http://llvm-reviews.chandlerc.com/D1831 Thanks! llvm-svn: 193294
* Refactor out the circular reference to LambdaExpr in CXXRecordDecl.Faisal Vali2013-10-231-25/+32
| | | | | | | | | | | | | | | | | A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box). Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. No change in functionality. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193246
* Revert r193223 and r193216.Rafael Espindola2013-10-231-32/+25
| | | | | | | | | | 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
* Remove the circular reference to LambdaExpr in CXXRecordDecl.Faisal Vali2013-10-231-25/+32
| | | | | | | | | | | | | | | Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl. No change in functionality. In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier. This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested): http://llvm-reviews.chandlerc.com/D1856 Thanks! llvm-svn: 193223
* Implement conversion to function pointer for generic lambdas without captures.Faisal Vali2013-09-291-6/+42
| | | | | | | | | | | | | | | | 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-281-0/+4
| | | | llvm-svn: 191609
* Switch from putting init capture VarDecls in the surrounding DeclContext toRichard Smith2013-09-281-1/+1
| | | | | | | | putting them in the call operator's DeclContext. This better matches the language wording and avoids some cases where code gets confused by them for namespace-scope lambdas and the like. llvm-svn: 191606
* Per latest drafting, switch to implementing init-captures as if by declaringRichard Smith2013-09-281-127/+88
| | | | | | and capturing a variable declaration, and complete the implementation of them. llvm-svn: 191605
OpenPOWER on IntegriCloud