summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaCXX/constant-expression-cxx11.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Modern gcc is happy to constant evaluate __builtin_strlen in various casesRichard Smith2013-11-151-0/+39
| | | | | | | where we didn't. Extend our constant evaluation for __builtin_strlen to handle any constant array of chars, not just string literals, to match. llvm-svn: 194762
* PR17800: When performing pack expansion, we must always rebuild the AST nodesRichard Smith2013-11-071-0/+13
| | | | | | | to avoid breaking AST invariants by reusing Stmt nodes within the same function. llvm-svn: 194217
* Refactor constant expression handling and make a couple of tweaks to make it aRichard Smith2013-11-051-0/+17
| | | | | | | | | bit more robust against future changes. This includes a slight diagnostic improvement: if we know we're only trying to form a constant expression, take the first diagnostic which shows the expression is not a constant expression, rather than preferring the first one which makes the expression unfoldable. llvm-svn: 194098
* Part three of PR15721: if we have an invalid CXXDefaultInitExpr, don't crash ifRichard Smith2013-09-131-0/+18
| | | | | | we try to constant-evaluate it. Patch by Karthik Bhat, test by me. llvm-svn: 190722
* PR5683: Issue a warning when subtracting pointers to types of zero size, andRichard Smith2013-09-101-1/+13
| | | | | | | treat such subtractions as being non-constant. Patch by Serge Pavlov! With a few tweaks by me. llvm-svn: 190439
* PR16755: When initializing or modifying a bitfield member in a constantRichard Smith2013-08-061-0/+37
| | | | | | expression, truncate the stored value to the size of the bitfield. llvm-svn: 187782
* C++1y: track object lifetime during constexpr evaluation, and don't allowRichard Smith2013-07-241-0/+18
| | | | | | | objects to be used once their lifetimes end. This completes the C++1y constexpr extensions. llvm-svn: 187025
* Fix error recovery with in-class initializer.Eli Friedman2013-06-281-0/+15
| | | | | | | | Previously, for a field with an invalid in-class initializer, we would create a CXXDefaultInitExpr referring to a null Expr*. This is not a good idea. llvm-svn: 185216
* More of N3652: don't add an implicit 'const' to 'constexpr' member functions ↵Richard Smith2013-06-251-0/+24
| | | | | | when checking for overloads in C++1y. llvm-svn: 184865
* PR16377: Allow evaluation of statement expressions in constant evaluation,Richard Smith2013-06-201-0/+21
| | | | | | why not. Apparently GCC supports this. llvm-svn: 184396
* Fix handling of const_cast from prvalue to rvalue reference: such a cast isRichard Smith2013-06-141-0/+5
| | | | | | | only permitted if the source object is of class type, and should materialize a temporary for the reference to bind to. llvm-svn: 184017
* Implement core issue 903: only integer literals with value 0 and prvalues ofRichard Smith2013-06-131-6/+13
| | | | | | type std::nullptr_t are null pointer constants from C++11 onwards. llvm-svn: 183883
* PR12086, PR15117Richard Smith2013-06-121-0/+41
| | | | | | | | | | | | | | | | | | | Introduce CXXStdInitializerListExpr node, representing the implicit construction of a std::initializer_list<T> object from its underlying array. The AST representation of such an expression goes from an InitListExpr with a flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr). This more detailed representation has several advantages, the most important of which is that the new MaterializeTemporaryExpr allows us to directly model lifetime extension of the underlying temporary array. Using that, this patch *drastically* simplifies the IR generation of this construct, provides IR generation support for nested global initializer_list objects, fixes several bugs where the destructors for the underlying array would accidentally not get invoked, and provides constant expression evaluation support for std::initializer_list objects. llvm-svn: 183872
* Recursively lifetime-extend into array temporaries. These can get implicitlyRichard Smith2013-06-081-0/+6
| | | | | | created through binding a reference-to-array to an initializer list. llvm-svn: 183594
* When a static storage duration temporary appears in a constant expression, itRichard Smith2013-06-061-0/+10
| | | | | | | | must be initialized by a constant expression (not just a core constant expression), because we're going to emit it as a global. Core issue for this is pending. llvm-svn: 183388
* Model temporary lifetime-extension explicitly in the AST. Use this model toRichard Smith2013-06-051-3/+42
| | | | | | | | | handle temporaries which have been lifetime-extended to static storage duration within constant expressions. This correctly handles nested lifetime extension (through reference members of aggregates in aggregate initializers) but non-constant-expression emission hasn't yet been updated to do the same. llvm-svn: 183283
* Refactor constant expression evaluation to associate the complete object of aRichard Smith2013-06-031-4/+9
| | | | | | | | | | | | | | materialized temporary with the corresponding MaterializeTemporaryExpr. This is groundwork for providing C++11's guaranteed static initialization for global references bound to lifetime-extended temporaries (if the initialization is a constant expression). In passing, fix a couple of bugs where some evaluation failures didn't trigger diagnostics, and a rejects-valid where potential constant expression testing would assume that it knew the dynamic type of *this and would reject programs which relied on it being some derived type. llvm-svn: 183093
* PR14772: Support constant expression evaluation for _Atomic types.Richard Smith2013-05-231-0/+25
| | | | | | | | | * Treat _Atomic(T) as a literal type if T is a literal type. * Evaluate expressions of this type properly. * Fix a lurking bug where we built completely bogus ASTs for converting to _Atomic types in C++ in some cases, caught by the tests for this change. llvm-svn: 182541
* Suppress bogus "use of undefined constexpr function" error if the function bodyRichard Smith2013-05-141-0/+8
| | | | | | was erroneous and got discarded. llvm-svn: 181758
* Handle parens properly when initializing a char array from a string literal.Richard Smith2013-05-051-0/+13
| | | | llvm-svn: 181159
* PR15884: In the 'taking the address of a temporary' extension, materialize theRichard Smith2013-05-011-0/+10
| | | | | | | | temporary to an lvalue before taking its address. This removes a weird special case from the AST representation, and allows the constant expression evaluator to deal with it without (broken) hacks. llvm-svn: 180866
* C++1y: support simple variable assignments in constexpr functions.Richard Smith2013-04-261-5/+5
| | | | llvm-svn: 180603
* C++1y constexpr extensions, round 1: Allow most forms of declaration andRichard Smith2013-04-221-0/+7
| | | | | | | | statement in constexpr functions. Everything which doesn't require variable mutation is also allowed as an extension in C++11. 'void' becomes a literal type to support constexpr functions which return 'void'. llvm-svn: 180022
* Fix array constant expression evaluation bug: we can have different values forRichard Smith2013-04-221-0/+18
| | | | | | | different array elements, even if they're all constructed using the same default constructor. llvm-svn: 180017
* The 'constexpr implies const' rule for non-static member functions is gone inRichard Smith2013-04-211-13/+13
| | | | | | | | | C++1y, so stop adding the 'const' there. Provide a compatibility warning for code relying on this in C++11, with a fix-it hint. Update our lazily-written tests to add the const, except for those ones which were testing our implementation of this rule. llvm-svn: 179969
* Clarify the diagnostic for -Wnested-anon-types.Richard Smith2013-01-311-2/+2
| | | | llvm-svn: 174032
* Add a -pedantic warning: an anonymous union within an anonymous union is notRichard Smith2013-01-281-2/+2
| | | | | | | permitted in standard C++, despite being silently accepted by many (all?) major C++ implementations. llvm-svn: 173643
* PR11851 (and duplicates): Whenever a constexpr function is referenced,Richard Smith2012-11-071-2/+3
| | | | | | | | | instantiate it if it can be instantiated and implicitly define it if it can be implicitly defined. This matches g++'s approach. Remove some cases from SemaOverload which were marking functions as referenced when just planning how overload resolution would proceed; such cases are not actually references. llvm-svn: 167514
* Partially roll back r166898; it exposed a bug in the standard.Richard Smith2012-10-291-4/+23
| | | | | | | | | | | | | The problem is as follows: C++11 has contexts which are not potentially-evaluated, and yet in which we are required or encouraged to perform constant evaluation. In such contexts, we are not permitted to implicitly define special member functions for literal types, therefore we cannot evalaute those constant expressions. Punt on this in one more context for now by skipping checking constexpr variable initializers if they occur in dependent contexts. llvm-svn: 166956
* When determining whether to try evaluating the initializer of a variable, checkRichard Smith2012-10-281-1/+8
| | | | | | | | | whether the initializer is value-dependent rather than whether we are in a dependent context. This allows us to detect some errors sooner, and fixes a crash-on-invalid if a dependent type leaks out to a non-dependent context in error recovery. llvm-svn: 166898
* PR14171: Don't crash if we hit one of the paths where GetFullTypeForDeclaratorRichard Smith2012-10-241-0/+9
| | | | | | rebuilds a function type, and that function type has parens around its name. llvm-svn: 166644
* DR1535: only potentially-evaluated typeid expressions are disallowed in constantRichard Smith2012-10-171-0/+11
| | | | | | expressions, not *any* typeid on a polymorphic class type. llvm-svn: 166156
* Fix treatment of case which came up on std-proposals@: 'void' is permitted ↵Richard Smith2012-10-011-0/+18
| | | | | | in core constant expressions, despite not being a literal type. llvm-svn: 164968
* Move TLS check from LValueExprEvaluator::VisitVarDecl toHans Wennborg2012-08-291-3/+12
| | | | | | | | | | | CheckLValueConstantExpression. Richard pointed out that using the address of a TLS variable is ok in a core C++11 constant expression, as long as it isn't part of the eventual result of constant expression evaluation. Having the check in CheckLValueConstantExpression accomplishes this. llvm-svn: 162850
* Fix r162835 as per Richard's comments.Hans Wennborg2012-08-291-0/+7
| | | | | | | VisitVarDecl should return Error(E), and we should test that the address of a TLS var can't be used as a constexpr. llvm-svn: 162837
* Implement warning for integral null pointer constants other than the literal 0.David Blaikie2012-08-081-1/+7
| | | | | | | | | | | | | | | | | | | | This is effectively a warning for code that violates core issue 903 & thus will become standard error in the future, hopefully. It catches strange null pointers such as: '\0', 1 - 1, const int null = 0; etc... There's currently a flaw in this warning (& the warning for 'false' as a null pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0' for example). Fix to come in a future patch. Also, due to this only being a warning, not an error, it triggers quite frequently on gtest code which tests expressions for null-pointer-ness in a SFINAE context (so it wouldn't be a problem if this was an error as in an actual implementation of core issue 903). To workaround this for now, the diagnostic does not fire in unevaluated contexts. Review by Sean Silva and Richard Smith. llvm-svn: 161501
* When building a conditional operator where one operand is a throw-expressionRichard Smith2012-08-071-3/+20
| | | | | | | | | and the other is a glvalue of class type, don't forget to copy-initialize a temporary when performing the lvalue-to-rvalue conversion on the glvalue. Strangely, DefaultLvalueConversions misses this part of the lvalue-to-rvalue conversions. llvm-svn: 161450
* Fix crash when constant-evaluating a CXXConstructExpr representingRichard Smith2012-07-101-0/+8
| | | | | | | value-initialization for an array of class type with a trivial default constructor. llvm-svn: 160024
* PR13290: Constant-evaluation support for CXXConstructExprs which construct aRichard Smith2012-07-071-0/+13
| | | | | | | | multidimensional array of class type. Also, preserve zero-initialization when evaluating an initializer list for an array, in case the initializers refer to later elements (which have preceding zero-initialization). llvm-svn: 159904
* PR12670: Support for initializing an array of non-aggregate class type from anRichard Smith2012-07-071-0/+12
| | | | | | | initializer list. Patch by Olivier Goffart, with extra testcases by Meador Inge and Daniel Lunow. llvm-svn: 159896
* PR13273: When performing list-initialization with an empty initializer list,Richard Smith2012-07-051-0/+16
| | | | | | | | | | | actually perform value initialization rather than trying to fake it with a call to the default constructor. Fixes various bugs related to the previously-missing zero-initialization in this case. I've also moved this and the other list initialization 'special case' from TryConstructorInitialization into TryListInitialization where they belong. llvm-svn: 159733
* Additional testing for fixes in r158289 and r158290 to allow implicitly-declaredRichard Smith2012-07-021-0/+25
| | | | | | constructors for non-literal types to be constexpr in some circumstances. llvm-svn: 159513
* Fix lifetime issue for backing APValue of OpaqueValueExpr in recursiveRichard Smith2012-06-261-0/+11
| | | | | | | | | | constexpr function evaluation, and corresponding ASan / valgrind issue in tests, by storing the corresponding value with the relevant stack frame. This also prevents re-evaluation of the source of the underlying OpaqueValueExpr, which makes a major performance difference for certain contrived code (see testcase update). llvm-svn: 159189
* PR12826: Converting an lvalue to an xvalue is a no-op conversion, not an ↵Richard Smith2012-05-151-0/+8
| | | | | | lvalue-to-rvalue conversion. llvm-svn: 156803
* My first effort to do this more subtly failed, so elaboratelyJohn McCall2012-05-011-0/+10
| | | | | | | test for an invalid declaration at every single place in the constant evaluator that's about to request a struct layout. llvm-svn: 155868
* PR12226: don't generate wrong code if a braced string literal is used toRichard Smith2012-04-151-0/+4
| | | | | | | | | initialize an array of unsigned char. Outside C++11 mode, this bug was benign, and just resulted in us emitting a constant which was double the required length, padded with 0s. In C++11, it resulted in us generating an array whose first element was something like i8 ptrtoint ([n x i8]* @str to i8). llvm-svn: 154756
* Allow vectors to be constructed from constexpr function arguments inRichard Smith2012-03-131-0/+14
| | | | | | constant expressions. llvm-svn: 152665
* Add -Wstring-plus-int, which warns on "str" + int and int + "str".Nico Weber2012-03-021-1/+1
| | | | | | | | It doesn't warn if the integer is known at compile time and within the bounds of the string. Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203 llvm-svn: 151943
* Ensure that we instantiate static reference data members of class templatesRichard Smith2012-03-021-2/+2
| | | | | | | | | early, since their values can be used in constant expressions in C++11. For odr-use checking, the opposite change is required, since references are odr-used whether or not they satisfy the requirements for appearing in a constant expression. llvm-svn: 151881
* Implement constant expression support for __real__ and __imag__ on lvalueRichard Smith2012-02-181-0/+22
| | | | | | | | | | | | | | | complex numbers. Treat complex numbers as arrays of the corresponding component type, in order to make std::complex behave properly if implemented in terms of _Complex T. Apparently libstdc++'s std::complex is implemented this way, and we were rejecting a member like this: constexpr double real() { return __real__ val; } because it was marked constexpr but unable to produce a constant expression. llvm-svn: 150895
OpenPOWER on IntegriCloud