summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaLambda.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Re-commit r183466 with a fix to make the TypeLoc casting machinery workEli Friedman2013-06-071-3/+3
| | | | | | | | | correctly in the presence of qualified types. (I had to change the unittest because it was trying to cast a QualifiedTypeLoc to TemplateSpecializationTypeLoc.) llvm-svn: 183563
* Reverts r183466: "Perform dynamic alignment computations..."Manuel Klimek2013-06-071-3/+3
| | | | | | | | | This introduces bugs in TemplateSpecializationTypeLoc's angle bracket locations. Regression test follows in a subsequent commit. llvm-svn: 183513
* Perform dynamic alignment computations so that the data in TypeLocs isEli Friedman2013-06-071-3/+3
| | | | | | | | | | | | | | | correctly aligned. Not performing such computations led to misaligned loads, which crash on some platforms and are generally bad on other platforms. The implementation of TypeLocBuilder::pushImpl is rather messy; code using TypeLocBuilder accidentally assumes that partial TypeLocs are laid out like a complete TypeLoc. As a followup, I intend to work on fixing the TypeLocBuilder API to avoid exposing partial TypeLocs; this should substantially simplify the implemementation. Fixes PR16144. llvm-svn: 183466
* First pass of semantic analysis for init-captures: check the initializer, buildRichard Smith2013-05-161-24/+136
| | | | | | | | | | | | | 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 n3648: parse and reject init-captures for now.Richard Smith2013-05-091-0/+8
| | | | llvm-svn: 181553
* In block enum-return inference, don't die on loads of enum lvalues.John McCall2013-05-081-3/+4
| | | | | | More of rdar://13200889. llvm-svn: 181390
* Replace ArrayRef<T>() with None, now that we have an implicit ArrayRef ↵Dmitri Gribenko2013-05-051-5/+3
| | | | | | | | constructor from None Patch by Robert Wilhelm. llvm-svn: 181139
* Move parsing of identifiers in MS-style inline assembly intoJohn McCall2013-05-031-0/+1
| | | | | | | | | | | | | | | | | | | | | the actual parser and support arbitrary id-expressions. We're actually basically set up to do arbitrary expressions here if we wanted to. Assembly operands permit things like A::x to be written regardless of language mode, which forces us to embellish the evaluation context logic somewhat. The logic here under template instantiation is incorrect; we need to preserve the fact that an expression was unevaluated. Of course, template instantiation in general is fishy here because we have no way of delaying semantic analysis in the MC parser. It's all just fishy. I've also fixed the serialization of MS asm statements. This commit depends on an LLVM commit. llvm-svn: 180976
* Sema for Captured StatementsTareq A. Siraj2013-04-161-0/+1
| | | | | | | | | | | | | Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic analysis. Currently captures all variables by reference. TODO: templates Author: Ben Langmuir <ben.langmuir@intel.com> Differential Revision: http://llvm-reviews.chandlerc.com/D433 llvm-svn: 179618
* Add 178663 back.Rafael Espindola2013-04-031-5/+2
| | | | | | | | | | | http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green before it processed the reverted 178663, so it could not have been the culprit. Revert "Revert 178663." This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41. llvm-svn: 178682
* Revert 178663.Rafael Espindola2013-04-031-2/+5
| | | | | | | | | | Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb Revert "Don't compute a patched/semantic storage class." This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05. llvm-svn: 178681
* Don't compute a patched/semantic storage class.Rafael Espindola2013-04-031-5/+2
| | | | | | | | | | | For variables and functions clang used to store two storage classes. The one "as written" in the code and a patched one, which, for example, propagates static to the following decls. This apparently is from the days clang lacked linkage computation. It is now redundant and this patch removes it. llvm-svn: 178663
* Adjust the special non-C++ enum block return type inferenceJohn McCall2013-03-091-86/+155
| | | | | | | | | | | | | | | so that it looks through certain syntactic forms and applies even if normal inference would have succeeded. There is potential for source incompatibility from this change, but overall we feel that it produces a much cleaner and more defensible result, and the block compatibility rules should curb a lot of the potential for annoyance. rdar://13200889 llvm-svn: 176743
* ArrayRef-ize ASTContext::getFunctionType and Sema::BuildFunctionType.Jordan Rose2013-03-081-11/+15
| | | | | | No (intended) functionality change. llvm-svn: 176726
* Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko2013-01-121-7/+7
| | | | | | brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
* Revert r170500. It over-zealously converted *ALL* things named Attributes, ↵Bill Wendling2012-12-201-1/+1
| | | | | | which is wrong here. llvm-svn: 170721
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-1/+1
| | | | | | single attribute in the future. llvm-svn: 170500
* Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as ↵David Blaikie2012-12-191-2/+2
| | | | | | | | | | | | | | | per review discussion in r170365 This does limit these typedefs to being sequences, but no current usage requires them to be contiguous (we could expand this to a more general iterator pair range concept at some point). Also, it'd be nice if SmallVector were constructible directly from an ArrayRef but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the inverse conversion. (& generalizing over all range-like things, while nice, would require some nontrivial SFINAE I haven't thought about yet) llvm-svn: 170482
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-2/+2
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Handle lambdas where the lambda-declarator is an explicit "(void)". PR13854.Eli Friedman2012-09-201-3/+9
| | | | llvm-svn: 164274
* Add the TypeSourceInfo for the lambda call operator to the lambda'sEli Friedman2012-09-191-4/+6
| | | | | | | | definition info; it needs to be there because the mangler needs to access it before we're finished defining the lambda class. PR12808. llvm-svn: 164186
* Add an extra check for invalid decls in the lambda semantic analysis to ↵Eli Friedman2012-09-181-0/+4
| | | | | | avoid a crash. PR13860. llvm-svn: 164168
* PR13652: Don't assume the parameter array on a FunctionTypeLoc for a lambda willRichard Smith2012-08-301-6/+5
| | | | | | | be filled in; they won't if the lambda's declarator has an invalid type. Instead take the parameters from the declarator directly. llvm-svn: 162904
* Provide isConst/Volatile on CXXMethodDecl.David Blaikie2012-08-101-1/+1
| | | | | | | | | This also provides isConst/Volatile/Restrict on FunctionTypes to coalesce the implementation with other callers (& update those other callers). Patch contributed by Sam Panzer (panzer@google.com). llvm-svn: 161647
* PR12057: Allow variadic template pack expansions to cross lambda boundaries.Richard Smith2012-07-251-18/+10
| | | | | | | | | | 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
* PR12917: Remove incorrect assumption that lambda mangling information cannotRichard Smith2012-07-221-58/+68
| | | | | | | | | | change once it's been assigned. It can change in two ways: 1) In a template instantiation, the context declaration should be the instantiated declaration, not the declaration in the template. 2) If a lambda appears in the pattern of a variadic pack expansion, the mangling number will depend on the pack length. llvm-svn: 160614
* Split out the "empty" case for compound statement into a separate ctor.Benjamin Kramer2012-07-041-3/+1
| | | | | | Move the ASTContext-dependent version out of line. llvm-svn: 159717
* In blocks, only pretend that enum constants have enum type if necessary.Jordan Rose2012-07-021-0/+137
| | | | | | | | | | | | | | | | | | In C, enum constants have the type of the enum's underlying integer type, rather than the type of the enum. (This is not true in C++.) Thus, when a block's return type is inferred from an enum constant, it is incompatible with expressions that return the enum type. In r158899, I told block returns to pretend that enum constants have enum type, like in C++. Doug Gregor pointed out that this can break existing code. Now, we don't check the types of return statements until the end of the block. This lets us go back and add implicit casts in blocks with mixed enum constants and enum-typed expressions. <rdar://problem/11662489> (again) llvm-svn: 159591
* Check the parameter lists and return type of both blocks and lambdasDouglas Gregor2012-06-151-1/+18
| | | | | | | for unexpanded parameter packs. Fixes the crash-on-invalid in PR13117. llvm-svn: 158525
* Revert Decl's iterators back to pointer value_type rather than reference ↵David Blaikie2012-06-061-2/+2
| | | | | | | | | | | | | | value_type In addition, I've made the pointer and reference typedef 'void' rather than T* just so they can't get misused. I would've omitted them entirely but std::distance likes them to be there even if it doesn't use them. This rolls back r155808 and r155869. Review by Doug Gregor incorporating feedback from Chandler Carruth. llvm-svn: 158104
* Removing the lambda extension warning concerning single return statements, ↵Aaron Ballman2012-06-041-20/+0
| | | | | | as it no longer applies. llvm-svn: 157943
* Remove the ref/value inconsistency in filter_decl_iterator.David Blaikie2012-04-301-2/+8
| | | | | | | | | | | | | filter_decl_iterator had a weird mismatch where both op* and op-> returned T* making it difficult to generalize this filtering behavior into a reusable library of any kind. This change errs on the side of value, making op-> return T* and op* return T&. (reviewed by Richard Smith) llvm-svn: 155808
* Move the computation of the lambda mangling information (manglingDouglas Gregor2012-04-041-78/+78
| | | | | | | | | | number + context) to the point where we initially start defining the lambda, so that the linkage won't change when that information is made available. Fixes the assertion in <rdar://problem/11182962>. Plus, actually mangle the context of lambdas properly. llvm-svn: 154029
* Unify naming of LangOptions variable/get function across the Clang stack ↵David Blaikie2012-03-111-1/+1
| | | | | | | | | | (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
* Implement "optimization" for lambda-to-block conversion which inlines the ↵Eli Friedman2012-03-011-0/+78
| | | | | | | | generated block literal for lambdas which are immediately converted to block pointer type. This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap. Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed. llvm-svn: 151797
* Generate an AST for the conversion from a lambda closure type to aDouglas Gregor2012-02-221-1/+1
| | | | | | | | | | | | | | | 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
* Only pop the expression evaluation context corresponding to a lambdaDouglas Gregor2012-02-211-5/+1
| | | | | | | | | expression after we've finished the function body of the corresponding function call operator. Otherwise, ActOnFinishFunctionBody() will see the (unfinished) evaluation context of the lambda expression itself. Fixes PR12031. llvm-svn: 151082
* Improve our handling of lambda expressions that occur within defaultDouglas Gregor2012-02-211-3/+12
| | | | | | | | | | | | | | | | | | | 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
* Remove comma from end of enum to silence build warning.Craig Topper2012-02-211-1/+1
| | | | llvm-svn: 151036
* Implement non-internal linkage for lambda closure types that need aDouglas Gregor2012-02-211-5/+34
| | | | | | | | | stable mangling, since these lambdas can end up in multiple translation units. Sema is responsible for deciding when this is the case, because it's already responsible for choosing the mangling number. llvm-svn: 151029
* Implement name mangling for lambda expressions that occur within theDouglas Gregor2012-02-211-9/+18
| | | | | | initializers of data members (both static and non-static). llvm-svn: 151017
* Implement name mangling for lambda expressions that occur within theDouglas Gregor2012-02-211-3/+30
| | | | | | | | | | | | | | | | default arguments of function parameters. This simple-sounding task is complicated greatly by two issues: (1) Default arguments aren't actually a real context, so we need to maintain extra state within lambda expressions to track when a lambda was actually in a default argument. (2) At the time that we parse a default argument, the FunctionDecl doesn't exist yet, so lambda closure types end up in the enclosing context. It's not clear that we ever want to change that, so instead we introduce the notion of the "effective" context of a declaration for the purposes of name mangling. llvm-svn: 151011
* Make sure that we set up the right declaration contexts when creatingDouglas Gregor2012-02-201-2/+2
| | | | | | | | | and introducing the lambda closure type and its function call operator. Previously, we assumed that the lambda closure type would land directly in the current context, and not some parent context (as occurs with linkage specifications). Thanks to Richard for the test case. llvm-svn: 150987
* Basic support for name mangling of C++11 lambda expressions. BecauseDouglas Gregor2012-02-201-2/+12
| | | | | | | | | | | | | | | name mangling in the Itanium C++ ABI for lambda expressions is so dependent on context, we encode the number used to encode each lambda as part of the lambda closure type, and maintain this value within Sema. Note that there are a several pieces still missing: - We still get the linkage of lambda expressions wrong - We aren't properly numbering or mangling lambda expressions that occur in default function arguments or in data member initializers. - We aren't (de-)serializing the lambda numbering tables llvm-svn: 150982
* Rewrite variable capture within lambda expressions and blocks,Douglas Gregor2012-02-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rework the Sema/AST/IRgen dance for the lambda closure type'sDouglas Gregor2012-02-171-5/+34
| | | | | | | | | | | | | | | | | | | | conversion to function pointer. Rather than having IRgen synthesize the body of this function, we instead introduce a static member function "__invoke" with the same signature as the lambda's operator() in the AST. Sema then generates a body for the conversion to function pointer which simply returns the address of __invoke. This approach makes it easier to evaluate a call to the conversion function as a constant, makes the linkage of the __invoke function follow the normal rules for member functions, and may make life easier down the road if we ever want to constexpr'ify some of lambdas. Note that IR generation is responsible for filling in the body of __invoke (Sema just adds a dummy body), because the body can't generally be expressed in C++. Eli, please review! llvm-svn: 150783
OpenPOWER on IntegriCloud