summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/expr/expr.prim
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement the last part of C++ [class.mem]p2, delaying the parsing ofDouglas Gregor2012-04-161-0/+10
| | | | | | | | | exception specifications on member functions until after the closing '}' for the containing class. This allows, for example, a member function to throw an instance of its own class. Fixes PR12564 and a fairly embarassing oversight in our C++98/03 support. llvm-svn: 154844
* Implement C++11 [expr.prim.general]p3, which permits the use of 'this'Douglas Gregor2012-04-161-0/+90
| | | | | | | | | | | | | | | | | | | | | | | in the declaration of a non-static member function after the (optional) cv-qualifier-seq, which in practice means in the exception specification and late-specified return type. The new scheme here used to manage 'this' outside of a member function scope is more general than the Scope-based mechanism previously used for non-static data member initializers and late-parsesd attributes, because it can also handle the cv-qualifiers on the member function. Note, however, that a separate pass is required for static member functions to determine whether 'this' was used, because we might not know that we have a static function until after declaration matching. Finally, this introduces name mangling for 'this' and for the implicit 'this', which is intended to match GCC's mangling. Independent verification for the new mangling test case would be appreciated. Fixes PR10036 and PR12450. llvm-svn: 154799
* Improve diagnostics for invalid use of non-static members / this:Richard Smith2012-04-053-4/+4
| | | | | | | | | | | | * s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted the former by 28-2 in our diagnostics. * Fix the "use of member in static member function" diagnostic to correctly detect this situation inside a block or lambda. * Produce a more specific "invalid use of non-static member" diagnostic for the case where a nested class member refers to a member of a lexically-surrounding class. llvm-svn: 154073
* Make the odr-use logic work correctly for constant-expressions. PR12006.Eli Friedman2012-02-291-3/+2
| | | | llvm-svn: 151699
* PR11956: C++11's special exception for accessing non-static data members fromRichard Smith2012-02-251-1/+9
| | | | | | unevaluated operands applies within member functions, too. llvm-svn: 151443
* Teach overload resolution to prefer user-defined conversion via aDouglas Gregor2012-02-221-0/+31
| | | | | | | | | | lambda closure type's function pointer conversion over user-defined conversion via a lambda closure type's block pointer conversion, always. This is a preference for more-standard code (since blocks are an extension) and a nod to efficiency, since function pointers don't require any memory management. Fixes PR12063. llvm-svn: 151170
* Generate an AST for the conversion from a lambda closure type to aDouglas Gregor2012-02-221-0/+0
| | | | | | | | | | | | | | | 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
* In the conflict between C++11 [expr.prim.general]p4, which declaresDouglas Gregor2012-02-211-0/+11
| | | | | | | | | | | that 'this' can be used in the brace-or-equal-initializer of a non-static data member, and C++11 [expr.prim.lambda]p9, which says that lambda expressions not in block scope can have no captures, side fully with C++11 [expr.prim.general]p4 by allowing 'this' to be captured within these initializers. This seems to be the intent of non-static data member initializers. llvm-svn: 151101
* Improve our handling of lambda expressions that occur within defaultDouglas Gregor2012-02-211-0/+6
| | | | | | | | | | | | | | | | | | | 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
* Rewrite variable capture within lambda expressions and blocks,Douglas Gregor2012-02-183-5/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Unify our computation of the type of a captured reference to aDouglas Gregor2012-02-182-2/+5
| | | | | | | variable; it was previously duplicated, and one of the copies failed to account for outer non-mutable lambda captures. llvm-svn: 150872
* Only add 'const' to the type of variables captured in a lambda whenDouglas Gregor2012-02-171-0/+4
| | | | | | we're capturing it by value in a non-mutable lambda. llvm-svn: 150791
* Lambda closure types are always considered to be like "local" classes,Douglas Gregor2012-02-161-0/+33
| | | | | | | | | even if they are not within a function scope. Teach template instantiation to treat them as such, and make sure that we have a local instantiation scope when instantiating default arguments and static data members. llvm-svn: 150725
* Implicitly define a lambda's conversion functions (to functionDouglas Gregor2012-02-161-0/+20
| | | | | | | | | | | | | pointers and block pointers). We use dummy definitions to keep the invariant that an implicit, used definition has a body; IR generation will substitute the actual contents, since they can't be represented as C++. For the block pointer case, compute the copy-initialization needed to capture the lambda object in the block, which IR generation will need later. llvm-svn: 150645
* Lambda closure types have a conversion function to a block pointerDouglas Gregor2012-02-151-0/+7
| | | | | | | | | | | 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
* When overload resolution picks an implicitly-deleted special memberDouglas Gregor2012-02-151-6/+3
| | | | | | | | | function, provide a specialized diagnostic that indicates the kind of special member function (default constructor, copy assignment operator, etc.) and that it was implicitly deleted. Add a hook where we can provide more detailed information later. llvm-svn: 150611
* A little more lambda capture initialization diagnostics cleanupDouglas Gregor2012-02-151-1/+8
| | | | llvm-svn: 150589
* Introduce a new initialization entity for lambda captures, andDouglas Gregor2012-02-151-3/+6
| | | | | | specialize location information and diagnostics for this entity. llvm-svn: 150588
* Specialize noreturn diagnostics for lambda expressions.Douglas Gregor2012-02-153-3/+5
| | | | llvm-svn: 150586
* Specialize the diagnostic complaining about conflicting types ofDouglas Gregor2012-02-151-2/+2
| | | | | | | return statements within a lambda; this diagnostic previously referred to blocks. llvm-svn: 150584
* Implement C++ core issue 974, which permits default arguments forDouglas Gregor2012-02-142-2/+53
| | | | | | | | 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-142-0/+16
| | | | llvm-svn: 150503
* Implement support for lambda capture pack expansions, e.g.,Douglas Gregor2012-02-141-0/+58
| | | | | | [&values...] { print(values...); } llvm-svn: 150497
* Simple test ensuring that we perform direct initialization when ↵Douglas Gregor2012-02-141-0/+9
| | | | | | copy-capturing in lambdas llvm-svn: 150442
* Link together the call operator produced from transforming a lambdaDouglas Gregor2012-02-141-0/+71
| | | | | | | | 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-0/+45
| | | | | | | | | | | | | | | | | | 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
* Within the body of a lambda expression, decltype((x)) for anDouglas Gregor2012-02-122-2/+43
| | | | | | | | | | | | | | | | id-expression 'x' will compute the type based on the assumption that 'x' will be captured, even if it isn't captured, per C++11 [expr.prim.lambda]p18. There are two related refactors that go into implementing this: 1) Split out the check that determines whether we should capture a particular variable reference, along with the computation of the type of the field, from the actual act of capturing the variable. 2) Always compute the result of decltype() within Sema, rather than AST, because the decltype() computation is now context-sensitive. llvm-svn: 150347
* Lambdas have a deleted default constructor and a deleted copyDouglas Gregor2012-02-124-0/+46
| | | | | | assignment operator, per C++ [expr.prim.lambda]p19. Make it so. llvm-svn: 150345
* Make sure Sema creates a field for 'this' captures. (Doug, please ↵Eli Friedman2012-02-111-0/+8
| | | | | | double-check that this is correct.) llvm-svn: 150292
* Add simple semantic test for C++11 [expr.prim.lambda]p16, which covers ↵Douglas Gregor2012-02-101-0/+16
| | | | | | recursive capture. This is far more interesting for IRgen. llvm-svn: 150283
* Implement C++11 [expr.lambda.prim]p13, which prohibits lambdas inDouglas Gregor2012-02-101-0/+10
| | | | | | default arguments if in fact those lambdas capture any entity. llvm-svn: 150282
* Allow implicit capture of 'this' in a lambda even when the captureDouglas Gregor2012-02-101-3/+7
| | | | | | | | | | | | 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
* Add test from [expr.prim.lambda]p12, which deals with odr-use andDouglas Gregor2012-02-101-0/+30
| | | | | | | | nested captures. We currently don't get odr-use correct in array bounds, so that bit is commented out while we sort out what we need to do. llvm-svn: 150255
* Don't introduce a lambda's operator() into the class until after weDouglas Gregor2012-02-101-0/+9
| | | | | | | | 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
* Add a lambda example from the working draft.Douglas Gregor2012-02-101-0/+9
| | | | llvm-svn: 150239
* Add various tests for captures and the reaching scope of the lambdaDouglas Gregor2012-02-103-0/+79
| | | | | | | expression. Implement C++11 [expr.prim.lambda]p12's requirement that capturing a variable will odr-use it. llvm-svn: 150237
* Implement the conversion to a function pointer for lambda expressions,Douglas Gregor2012-02-102-3/+25
| | | | | | per C++ [expr.prim.lambda]p6. llvm-svn: 150236
* Don't allow deduction of a lambda result type from an initializerDouglas Gregor2012-02-091-0/+1
| | | | | | list; it is not an expression. llvm-svn: 150194
* Tests for C++ [expr.prim.lambda]p5. We already implement all of theseDouglas Gregor2012-02-091-3/+57
| | | | | | semantics. llvm-svn: 150190
* Implement return type deduction for lambdas per C++11Douglas Gregor2012-02-091-0/+42
| | | | | | | | | [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
* Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor2012-02-099-52/+38
| | | | | | and rapidly becoming untrue. llvm-svn: 150165
* Add a test for the non-aggregaticity of lambda types per C++11Douglas Gregor2012-02-091-0/+7
| | | | | | [expr.prim.lambda]. llvm-svn: 150164
* Implement C++ [expr.prim.lambda]p2, which bans lambda expressions inDouglas Gregor2012-02-091-0/+48
| | | | | | | unevaluated operands. Be certain that we're marking everything referenced within a capture initializer as odr-used. llvm-svn: 150163
* Implement capture-by-copy for arrays in lambdas.Douglas Gregor2012-02-092-3/+16
| | | | llvm-svn: 150138
* When we create a non-static data member in the closure object for aDouglas Gregor2012-02-091-0/+17
| | | | | | capture, make sure we actually add the field. llvm-svn: 150135
* Various interrelated cleanups for lambdas:Douglas Gregor2012-02-096-25/+43
| | | | | | | | | | | | | | - Complete the lambda class when we finish the lambda expression (previously, it was left in the "being completed" state) - Actually return the LambdaExpr object and bind to the resulting temporary when needed. - Detect when cleanups are needed while capturing a variable into a lambda (e.g., due to default arguments in the copy constructor), and make sure those cleanups apply for the whole of the lambda expression. llvm-svn: 150123
* Minor comment fixDouglas Gregor2012-02-081-1/+2
| | | | llvm-svn: 150090
* When computing the type of a local variable reference within a lambda,Douglas Gregor2012-02-081-2/+35
| | | | | | | | only add 'const' for variables captured by copy in potentially evaluated expressions of non-mutable lambdas. (The "by copy" part was missing). llvm-svn: 150088
* When completing a lambda expression, make sure to check and attach theDouglas Gregor2012-02-082-2/+14
| | | | | | body of the lambda to the function call operator. llvm-svn: 150087
* Introduce basic ASTs for lambda expressions. This covers:Douglas Gregor2012-02-072-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | - Capturing variables by-reference and by-copy within a lambda - The representation of lambda captures - The creation of the non-static data members in the lambda class that store the captured variables - The initialization of the non-static data members from the captured variables - Pretty-printing lambda expressions There are a number of FIXMEs, both explicit and implied, including: - Creating a field for a capture of 'this' - Improved diagnostics for initialization failures when capturing variables by copy - Dealing with temporaries created during said initialization - Template instantiation - AST (de-)serialization - Binding and returning the lambda expression; turning it into a proper temporary - Lots and lots of semantic constraints - Parameter pack captures llvm-svn: 149977
OpenPOWER on IntegriCloud