summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaLambda.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Implement a rudimentary form of generic lambdas.Faisal Vali2013-09-261-27/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor to use C++1y 'auto' semantics directly in lambdas with no specifiedRichard Smith2013-09-251-14/+40
| | | | | | | return type in C++1y mode. No functionality change intended. Extracted and tweaked from a patch by Faisal Vali! llvm-svn: 191354
* [ms-cxxabi] Implement guard variables for static initializationReid Kleckner2013-09-101-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
* Note when a decl is used in AST files.Eli Friedman2013-09-051-1/+1
| | | | | | | | | | | | | | | When an AST file is built based on another AST file, it can use a decl from the fist file, and therefore mark the "isUsed" bit. We need to note this in the AST file so that the bit is set correctly when the second AST file is loaded. This patch introduces the distinction between setIsUsed() and markUsed() so that we don't call into the ASTMutationListener callback when it wouldn't be appropriate. Fixes PR16635. llvm-svn: 190016
* Delete CC_Default and use the target default CC everywhereReid Kleckner2013-08-271-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Makes functions with implicit calling convention compatible with function types with a matching explicit calling convention. This fixes things like calls to qsort(), which has an explicit __cdecl attribute on the comparator in Windows headers. Clang will now infer the calling convention from the declarator. There are two cases when the CC must be adjusted during redeclaration: 1. When defining a non-inline static method. 2. When redeclaring a function with an implicit or mismatched convention. Fixes PR13457, and allows clang to compile CommandLine.cpp for the Microsoft C++ ABI. Excellent test cases provided by Alexander Zinenko! Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1231 llvm-svn: 189412
* Revert "Implement a rudimentary form of generic lambdas."Manuel Klimek2013-08-221-129/+30
| | | | | | This reverts commit 606f5d7a99b11957e057e4cd1f55f931f66a42c7. llvm-svn: 189004
* Revert "Remove some unused variables identified by Juergen Ributzka *I need ↵Manuel Klimek2013-08-221-0/+1
| | | | | | | | to turn on this warning in Visual C++ - sorry!*" This reverts commit d01d0b63d87ac465f15ce1d6b56bf3faf4525769. llvm-svn: 189003
* Remove some unused variables identified by Juergen Ributzka *I need to turn ↵Faisal Vali2013-08-221-1/+0
| | | | | | on this warning in Visual C++ - sorry!* llvm-svn: 188979
* Implement a rudimentary form of generic lambdas.Faisal Vali2013-08-221-30/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Expose LambdaIntroducer::DefaultLoc in the AST's LambdaExpr.James Dennett2013-08-091-2/+10
| | | | | | | | | | | | | | | | | | | | | Summary: Source-centric tools need access to the location of a C++11 lambda expression's capture-default ('&' or '=') when it's present. It's possible for them to find it by re-lexing and re-implementing rules that Clang's parser has already applied, but the cost of storing the SourceLocation and making it available to them is 32 bits per LambdaExpr (a small delta, proportionally), and the simplification in client code is significant. Reviewers: rsmith Reviewed By: rsmith CC: cfe-commits, klimek, revane Differential Revision: http://llvm-reviews.chandlerc.com/D1192 llvm-svn: 188121
* More local mangling fixes.Eli Friedman2013-07-101-1/+1
| | | | | | | | | | | | Compute mangling numbers for externally visible local variables and tags. Change the mangler to consistently use discriminators where necessary. Tweak the scheme we use to number decls which are not externally visible to avoid unnecessary discriminators in common cases now that we request them more consistently. Fixes <rdar://problem/14204721>. llvm-svn: 185986
* Use SmallVectorImpl instead of SmallVector for iterators and references to ↵Craig Topper2013-07-041-4/+4
| | | | | | avoid specifying the vector size unnecessarily. llvm-svn: 185610
* Suppress "control reaches end of non-void function" warning when compiling ↵Andy Gibbs2013-07-021-0/+2
| | | | | | with gcc. llvm-svn: 185439
* Fix mangling for block literals.Eli Friedman2013-07-011-67/+72
| | | | | | | | | | | | | | | 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
* Unify return type checking for functions and ObjC methods. Move all theEli Friedman2013-06-141-3/+0
| | | | | | | | random checks for ObjC object return types to SemaType.cpp. Fixes issue with ObjC method type checking reported on cfe-dev. llvm-svn: 184006
* Followup to r183931 to fix the lambda conversion-to-block-pointer member.Eli Friedman2013-06-131-1/+1
| | | | llvm-svn: 183942
* Fix a small bug in the linkage computation for the lambda ↵Eli Friedman2013-06-131-1/+1
| | | | | | conversion-to-function-pointer member. llvm-svn: 183931
* Use FPT::getArgTypes() instead of manually building ArrayRefsReid Kleckner2013-06-101-15/+6
| | | | | | | | Made significantly easier with git-clang-format. Differential Revision: http://llvm-reviews.chandlerc.com/D947 llvm-svn: 183694
OpenPOWER on IntegriCloud