summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaLambda.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Lambda closure types have a conversion function to a block pointerDouglas Gregor2012-02-151-0/+50
| | | | | | | | | | | with the same parameter types and return type as the function call operator. This is the real answer to http://stackoverflow.com/questions/4148242/is-it-possible-to-convert-a-c0x-lambda-to-a-clang-block :) llvm-svn: 150620
* Factor the construction of the lambda-to-function-pointer conversion ↵Douglas Gregor2012-02-151-38/+48
| | | | | | function declaration into a separate function. No functionality change llvm-svn: 150617
* Implement C++ core issue 974, which permits default arguments forDouglas Gregor2012-02-141-21/+28
| | | | | | | | lambda expressions. Because these issue was pulled back from Ready status at the Kona meeting, we still emit an ExtWarn when using default arguments for lambda expressions. llvm-svn: 150519
* Check the return type of lambda expressions.Douglas Gregor2012-02-141-4/+13
| | | | llvm-svn: 150503
* Implement support for lambda capture pack expansions, e.g.,Douglas Gregor2012-02-141-3/+19
| | | | | | [&values...] { print(values...); } llvm-svn: 150497
* Link together the call operator produced from transforming a lambdaDouglas Gregor2012-02-141-13/+15
| | | | | | | | expression with the original call operator, so that we don't try to separately instantiate the call operator. Test and tweak a few more bits for template instantiation of lambda expressions. llvm-svn: 150440
* Introduce support for template instantiation of lambdaDouglas Gregor2012-02-131-87/+131
| | | | | | | | | | | | | | | | | | expressions. This is mostly a simple refact, splitting the main "start a lambda expression" function into smaller chunks that are driven either from the parser (Sema::ActOnLambdaExpr) or during AST transformation (TreeTransform::TransformLambdaExpr). A few minor interesting points: - Added new entry points for TreeTransform, so that we can explicitly establish the link between the lambda closure type in the template and the lambda closure type in the instantiation. - Added a bit into LambdaExpr specifying whether it had an explicit result type or not. We should have had this anyway. This code is 'lightly' tested. llvm-svn: 150417
* Keep track of the set of array index variables we use when weDouglas Gregor2012-02-131-1/+6
| | | | | | | synthesize a by-copy captured array in a lambda. This information will be needed by IR generation. llvm-svn: 150396
* Move the storage of lambda captures and capture initializers fromDouglas Gregor2012-02-131-7/+2
| | | | | | | | LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the back-link from the closure type to the LambdaExpr, which will simplify and lazify AST deserialization. llvm-svn: 150393
* Lambdas have a deleted default constructor and a deleted copyDouglas Gregor2012-02-121-7/+7
| | | | | | assignment operator, per C++ [expr.prim.lambda]p19. Make it so. llvm-svn: 150345
* Allow implicit capture of 'this' in a lambda even when the captureDouglas Gregor2012-02-101-6/+20
| | | | | | | | | | | | default is '=', and reword the warning about explicitly capturing 'this' in such lambdas to indicate that only explicit capture is banned. Introduce Fix-Its for this and other "save the programmer from themself" rules regarding what can be explicitly captured and what must be implicitly captured. llvm-svn: 150256
* Don't introduce a lambda's operator() into the class until after weDouglas Gregor2012-02-101-49/+51
| | | | | | | | have finished parsing the body, so that name lookup will never find anything within the closure type. Then, add this operator() and the conversion function (if available) before completing the class. llvm-svn: 150252
* Track whether a function type has a trailing return type as type sugar. Use thisRichard Smith2012-02-101-0/+1
| | | | | | | | | | | to pretty-print such function types better, and to fix a case where we were not instantiating templates in lexical order. In passing, move the Variadic bit from Type's bitfields to FunctionProtoType to get the Type bitfields down to 32 bits. Also ensure that we always substitute the return type of a function when substituting explicitly-specified arguments, since that can cause us to bail out with a SFINAE error before we hit a hard error in parameter substitution. llvm-svn: 150241
* Implement the conversion to a function pointer for lambda expressions,Douglas Gregor2012-02-101-2/+49
| | | | | | per C++ [expr.prim.lambda]p6. llvm-svn: 150236
* Extend CXXRecordDecl with a function that determines the mapping fromDouglas Gregor2012-02-101-1/+2
| | | | | | | the variables captured by a lambda to the fields that store the captured values. To be used in IRgen. llvm-svn: 150235
* Implement return type deduction for lambdas per C++11Douglas Gregor2012-02-091-1/+46
| | | | | | | | | [expr.prim.lambda]p4, including the current suggested resolution of core isue 975, which allows multiple return statements so long as the types match. ExtWarn when user code is actually making use of this extension. llvm-svn: 150168
* Restore the appropriate lexical declaration context for a lambda'sDouglas Gregor2012-02-091-1/+3
| | | | | | | | | | | function call operator (to the lambda class). This allows us to IRgen calls to simple (non-capturing) lambdas, e.g., [](int i, int j) -> int { return i + j; }(1, 2) Eli will be providing test cases as he brings up more IRgen. llvm-svn: 150166
* Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor2012-02-091-2/+0
| | | | | | and rapidly becoming untrue. llvm-svn: 150165
OpenPOWER on IntegriCloud