summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
* Make the odr-use logic work correctly for constant-expressions. PR12006.Eli Friedman2012-02-291-3/+2
| | | | llvm-svn: 151699
* Convert initializer lists to temporaries in CreateBuiltinBinOp. Allows ↵Sebastian Redl2012-02-271-3/+2
| | | | | | assignment of init lists to built-in types and resolves PR12088. llvm-svn: 151551
* Ensure that we delete default constructors in the right cases. Don't delete theRichard Smith2012-02-271-11/+16
| | | | | | | default constructor of a union if it has a const member with no user-provided default constructor. llvm-svn: 151516
* Tests for r151508.Richard Smith2012-02-261-0/+32
| | | | llvm-svn: 151509
* Don't assert when trying to diagnose why a class with a constructor template isRichard Smith2012-02-261-0/+4
| | | | | | non-trivial. llvm-svn: 151486
* Ensure that we delete destructors in the right cases. Specifically:Richard Smith2012-02-261-0/+103
| | | | | | | | | | | | | | - variant members with nontrivial destructors make the containing class's destructor deleted - check for a virtual destructor after checking for overridden methods in the base class(es) - check for an inaccessible operator delete for a class with a virtual destructor. Do not try to call an anonymous union field's destructor from the destructor of the containing class. llvm-svn: 151483
* Special members which are defaulted or deleted on their first declaration areRichard Smith2012-02-262-6/+4
| | | | | | | | | | | | | trivial if the implicit declaration would be. Don't forget to set the Trivial flag on the special member as well as on the class. It doesn't seem ideal that we have two separate mechanisms for storing this information, but this patch does not attempt to address that. This leaves us in an interesting position where the has_trivial_X trait for a class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'. This seems to be what the standard requires. llvm-svn: 151465
* 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
* Add test for C++ DR899.Douglas Gregor2012-02-241-0/+22
| | | | llvm-svn: 151411
* Implement C++11 [over.match.copy]p1b2, which allows the use ofDouglas Gregor2012-02-241-0/+15
| | | | | | | | | | | explicit conversion functions to initialize the argument to a copy/move constructor that itself is the subject of direct initialization. Since we don't have that much context in overload resolution, we end up threading more flags :(. Fixes <rdar://problem/10903741> / PR10456. llvm-svn: 151409
* 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
* Accept braced-init-lists in conditions, and, in passing, dramatically improveRichard Smith2012-02-221-3/+3
| | | | | | the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
* 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
* Improve diagnostics a bit for bad member initializers, and fix an obscure ↵Eli Friedman2012-02-221-0/+10
| | | | | | bug involving packs. Fixes PR12049. llvm-svn: 151130
* Implement C++11 [expr.call]p11: If the operand to a decltype-specifier is aRichard Smith2012-02-221-0/+108
| | | | | | | | | | | | | | | | | | function call (or a comma expression with a function call on its right-hand side), possibly parenthesized, then the return type is not required to be complete and a temporary is not bound. Other subexpressions inside a decltype expression do not get this treatment. This is implemented by deferring the relevant checks for all calls immediately within a decltype expression, then, when the expression is fully-parsed, checking the relevant constraints and stripping off any top-level temporary binding. Deferring the completion of the return type exposed a bug in overload resolution where completion of the argument types was not attempted, which is also fixed by this change. llvm-svn: 151117
* 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
* Make RequireLiteralType work correctly with incomplete array types. PR12037.Eli Friedman2012-02-201-0/+17
| | | | llvm-svn: 151005
* Fix a constexpr FIXME: When implicitly instantiating the primary template for anRichard Smith2012-02-201-9/+7
| | | | | | | explicit specialization of a function template, mark the instantiation as constexpr if the specialization is, rather than requiring them to match. llvm-svn: 151001
* 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
* Make sure we still reject static data members in anonymous unions in C++11.Richard Smith2012-02-161-0/+12
| | | | llvm-svn: 150724
* C++11 allows unions to have static data members. Remove the correspondingRichard Smith2012-02-162-1/+38
| | | | | | restriction and add some tests. llvm-svn: 150721
* constexpr tidyups:Richard Smith2012-02-161-5/+10
| | | | | | | | * Fix bug when determining whether && / || are potential constant expressions * Try harder when determining whether ?: is a potential constant expression * Produce a diagnostic on sizeof(VLA) to provide a better source location llvm-svn: 150657
* 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-155-47/+47
| | | | | | | | | 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 DR1454. This allows all intermediate results in constant expressionsRichard Smith2012-02-151-14/+12
| | | | | | | | | | | | to be core constant expressions (including pointers and references to temporaries), and makes constexpr calculations Turing-complete. A Turing machine simulator is included as a testcase. This opens up the possibilty of removing CCValue entirely, and removing some copies from the constant evaluator in the process, but that cleanup is not part of this change. llvm-svn: 150557
* 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
* Deal with a horrible C++11 special case. If a non-literal type has a constexprRichard Smith2012-02-131-3/+3
| | | | | | | | | | | constructor, and that constructor is used to initialize an object of static storage duration such that all members and bases are initialized by constant expressions, constant initialization is performed. In this case, the object can still have a non-trivial destructor, and if it does, we must emit a dynamic initializer which performs no initialization and instead simply registers that destructor. llvm-svn: 150419
* 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
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-139-89/+86
| | | | | | | | | | | | | | | | | | | | 1358, 1360, 1452 and 1453. - Instantiations of constexpr functions are always constexpr. This removes the need for separate declaration/definition checking, which is now gone. - This makes it possible for a constexpr function to be virtual, if they are only dependently virtual. Virtual calls to such functions are not constant expressions. - Likewise, it's now possible for a literal type to have virtual base classes. A constexpr constructor for such a type cannot actually produce a constant expression, though, so add a special-case diagnostic for a constructor call to such a type rather than trying to evaluate it. - Classes with trivial default constructors (for which value initialization can produce a fully-initialized value) are considered literal types. - Classes with volatile members are not literal types. - constexpr constructors can be members of non-literal types. We do not yet use static initialization for global objects constructed in this way. llvm-svn: 150359
* Implement the standard decltype() semantics described in C++11Douglas Gregor2012-02-121-0/+6
| | | | | | | | [dcl.type.simple]p4, which treats all xvalues as returning T&&. We had previously implemented a pre-standard variant of decltype() that doesn't cope with, e.g., static_ast<T&&>(e) very well. llvm-svn: 150348
* 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
* Represent C++ direct initializers as ParenListExprs before semantic analysisSebastian Redl2012-02-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of having a special-purpose function. - ActOnCXXDirectInitializer, which was mostly duplication of AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days ago), is dropped completely. - MultiInitializer, which was an ugly hack I added, is dropped again. - We now have the infrastructure in place to distinguish between int x = {1}; int x({1}); int x{1}; -- VarDecl now has getInitStyle(), which indicates which of the above was used. -- CXXConstructExpr now has a flag to indicate that it represents list- initialization, although this is not yet used. - InstantiateInitializer was renamed to SubstInitializer and simplified. - ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which always produces a ParenListExpr. Placed that so far failed to convert that back to a ParenExpr containing comma operators have been fixed. I'm pretty sure I could have made a crashing test case before this. The end result is a (I hope) considerably cleaner design of initializers. More importantly, the fact that I can now distinguish between the various initialization kinds means that I can get the tricky generalized initializer test cases Johannes Schaub supplied to work. (This is not yet done.) This commit passed self-host, with the resulting compiler passing the tests. I hope it doesn't break more complicated code. It's a pretty big change, but one that I feel is necessary. llvm-svn: 150318
* 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
OpenPOWER on IntegriCloud