summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/expr/expr.const
Commit message (Collapse)AuthorAgeFilesLines
* If constant evaluation fails due to an unspecified pointer comparison,Richard Smith2019-12-161-15/+15
| | | | | produce a note saying that rather than the default "evaluation failed" note.
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-291-0/+43
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* For P0784R7: add support for explicit destructor calls andRichard Smith2019-09-271-1/+1
| | | | | | pseudo-destructor calls in constant evaluation. llvm-svn: 373122
* For P0784R7: Add support for dynamic allocation with new / delete duringRichard Smith2019-09-271-16/+17
| | | | | | constant evaluation. llvm-svn: 373036
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-121-2/+2
| | | | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. llvm-svn: 360538
* Revert rL360499 and rL360464 from cfe/trunk:Simon Pilgrim2019-05-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. ........ Fix handling of objects under construction during constant expression evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. ........ Fixes windows buildbots llvm-svn: 360531
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-111-2/+2
| | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. llvm-svn: 360499
* P0859R0: List-initialization is potentially-constant-evaluated andRichard Smith2018-09-261-0/+39
| | | | | | | | | | | | triggers instantiation of constexpr functions. We mostly implemented this since Clang 6, but missed the template instantiation case. We do not implement the '&cast-expression' special case. It appears to be a mistake / oversight. I've mailed CWG to see if we can remove it. llvm-svn: 343064
* Don't warn about runtime behavior problems in variable initializers that weRichard Smith2017-09-231-7/+7
| | | | | | | | know are going to be constant-evaluated. Any relevant diagnostics should be produced by constant expression evaluation. llvm-svn: 314067
* DR616, and part of P0135R1: member access (or pointer-to-member access) on aRichard Smith2016-12-031-3/+3
| | | | | | | temporary produces an xvalue, not a prvalue. Support this by materializing the temporary prior to performing the member access. llvm-svn: 288563
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. This is a re-commit of r284800. llvm-svn: 284890
* Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' ↵Renato Golin2016-10-211-9/+9
| | | | | | | | rules." This reverts commit r284800, as it failed all ARM/AArch64 bots. llvm-svn: 284811
* DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.Richard Smith2016-10-211-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | This has two significant effects: 1) Direct relational comparisons between null pointer constants (0 and nullopt) and pointers are now ill-formed. This was always the case for C, and it appears that C++ only ever permitted by accident. For instance, cases like nullptr < &a are now rejected. 2) Comparisons and conditional operators between differently-cv-qualified pointer types now work, and produce a composite type that both source pointer types can convert to (when possible). For instance, comparison between 'int **' and 'const int **' is now valid, and uses an intermediate type of 'const int *const *'. Clang previously supported #2 as an extension. We do not accept the cases in #1 as an extension. I've tested a fair amount of code to check that this doesn't break it, but if it turns out that someone is relying on this, we can easily add it back as an extension. llvm-svn: 284800
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-161-2/+13
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Improve -Wconstant-conversionRichard Trieu2016-01-291-2/+2
| | | | | | | | | | | | | | Switch the evaluation from isIntegerConstantExpr to EvaluateAsInt. EvaluateAsInt will evaluate more types of expressions than isIntegerConstantExpr. Move one case from -Wsign-conversion to -Wconstant-conversion. The case is: 1) Source and target types are signed 2) Source type is wider than the target type 3) The source constant value is positive 4) The conversion will store the value as negative in the target. llvm-svn: 259271
* PR17381: Treat undefined behavior during expression evaluation as an unmodeledRichard Smith2015-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | side-effect, so that we don't allow speculative evaluation of such expressions during code generation. This caused a diagnostic quality regression, so fix constant expression diagnostics to prefer either the first "can't be constant folded" diagnostic or the first "not a constant expression" diagnostic depending on the kind of evaluation we're doing. This was always the intent, but didn't quite work correctly before. This results in certain initializers that used to be constant initializers to no longer be; in particular, things like: float f = 1e100; are no longer accepted in C. This seems appropriate, as such constructs would lead to code being executed if sanitizers are enabled. llvm-svn: 254574
* Update tests touched by r249656David Majnemer2015-10-081-1/+1
| | | | | | | | | These test updates almost exclusively around the change in behavior around enum: enums without a definition are considered incomplete except when targeting MSVC ABIs. Since these tests are interested in the 'incomplete-enum' behavior, restrict them to %itanium_abi_triple. llvm-svn: 249660
* [Sema] Warn when shifting a negative value.Davide Italiano2015-07-061-1/+1
| | | | | | | | | | | | | | | Example: % ./clang -Wshift-negative-value emit.c emit.c:3:14: warning: shifting a negative signed value is undefined [-Wshift-negative-value] int a = -1 << 3; ~~ ^ 1 warning generated. PR: 24026 Differential Revision: http://reviews.llvm.org/D10938 Reviewed by: rsmith llvm-svn: 241478
* [c++1z] Most of N4268 (allow constant evaluation for non-type template ↵Richard Smith2014-11-261-3/+3
| | | | | | | | | arguments). We don't yet support pointer-to-member template arguments that have undergone pointer-to-member conversions, mostly because we don't have a mangling for them yet. llvm-svn: 222807
* PR21180: Lambda closure types are neither aggregates nor literal types.Richard Smith2014-10-071-1/+1
| | | | llvm-svn: 219222
* PR19346: Adding 0 to a null pointer has defined behavior in C++. Allow it in ↵Richard Smith2014-04-081-1/+3
| | | | | | constant expressions. llvm-svn: 205757
* Creating a printing policy for "half":Yunzhong Gao2014-03-181-1/+1
| | | | | | | | | | | | Since "half" is an OpenCL keyword and clang accepts __fp16 as an extension for other languages, error messages and metadata (and hence debug info) should refer to the half-precision floating point as "__fp16" instead of "half" when compiling for non-OpenCL languages. This patch creates a new printing policy for half in a similar manner to what is done for bool and wchar_t. Differential Revision: http://llvm-reviews.chandlerc.com/D2952 llvm-svn: 204164
* Revert "Don't require -re suffix on -verify directives with regexes."Alp Toker2013-12-141-1/+1
| | | | | | | | | | This patch was submitted to the list for review and didn't receive a LGTM. (In fact one explicit objection and one query were raised.) This reverts commit r197295. llvm-svn: 197299
* Don't require -re suffix on -verify directives with regexes.Hans Wennborg2013-12-141-1/+1
| | | | | | Differential Revision: http://llvm-reviews.chandlerc.com/D2392 llvm-svn: 197295
* Tighten test regexes checking for __attribute__((thiscall)) on function types.Hans Wennborg2013-12-131-1/+1
| | | | | | | | | | | The tests were perhaps made too relaxed in r197164 when we switched to the new MinGW ABI. This makes sure we check explicitly for an optional thiscall attribute and nothing else. We should still look into whether we should print these attributes at all in these cases. llvm-svn: 197252
* Switch to the new MingW ABI.Rafael Espindola2013-12-121-1/+1
| | | | | | | GCC 4.7 changed the MingW ABI. On the clang side this means that methods now have the thiscall calling convention by default. llvm-svn: 197164
* Sema: Do not allow lambda expressions to appear inside of constant expressionsDavid Majnemer2013-10-251-3/+1
| | | | | | | | | We would previously not diagnose this which would lead to crashes (on very strange code). This fixes PR17675. llvm-svn: 193397
* FIXME fix: improving diagnostics for template arguments deduction of class ↵Larisse Voufo2013-07-191-1/+1
| | | | | | | | templates and explicit specializations This patch essentially removes all the FIXMEs following calls to DeduceTemplateArguments() that want to keep track of deduction failure info. llvm-svn: 186730
* Revert "Use function overloading instead of template specialization for ↵Larisse Voufo2013-07-191-1/+1
| | | | | | | | diagnosis of bad template argument deductions." This reverts commit a730f548325756d050d4caaa28fcbffdae8dfe95. llvm-svn: 186729
* Use function overloading instead of template specialization for diagnosis of ↵Larisse Voufo2013-07-191-1/+1
| | | | | | bad template argument deductions. llvm-svn: 186727
* Fix handling of const_cast from prvalue to rvalue reference: such a cast isRichard Smith2013-06-141-1/+1
| | | | | | | only permitted if the source object is of class type, and should materialize a temporary for the reference to bind to. llvm-svn: 184017
* Refactor constant expression evaluation to associate the complete object of aRichard Smith2013-06-031-2/+4
| | | | | | | | | | | | | | 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
* The 'constexpr implies const' rule for non-static member functions is gone inRichard Smith2013-04-213-11/+11
| | | | | | | | | 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
* Don't crash while printing APValues that are lvalues casted to aDouglas Gregor2013-01-291-0/+13
| | | | | | decidedly non-reference, non-pointer type. Fixes <rdar://problem/13090123>. llvm-svn: 173747
* Teach Clang parser to reject C++11 attributes that appertain to declaration ↵Michael Han2012-11-061-4/+4
| | | | | | | | | specifiers. We don't support any C++11 attributes that appertain to declaration specifiers so reject the attributes in parser until we support them; this also conforms to what g++ 4.8 is doing. llvm-svn: 167481
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-191-0/+1
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* Revert r163829. The world (or libstdc++, at least) is not ready.Richard Smith2012-09-131-6/+5
| | | | llvm-svn: 163846
* Remove speculative fix for C++ core issue 1407, since it was resolved as NAD.Richard Smith2012-09-131-5/+6
| | | | llvm-svn: 163829
* Don't treat overflow in floating-point conversions as a hard error in ↵Eli Friedman2012-07-171-3/+3
| | | | | | constant evaluation. <rdar://problem/11874571>. llvm-svn: 160394
* Extend -Wc++11-narrowing to cover converted constant expressions as well as ↵Eli Friedman2012-03-291-0/+8
| | | | | | braced-initializers. <rdar://problem/11121178>. llvm-svn: 153703
* 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 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
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-7/+12
| | | | | | | | | | | | | | | | | | | | 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
* Update to new resolution for DR1458. When taking the address of an object ofRichard Smith2012-02-101-3/+4
| | | | | | | incomplete class type which has an overloaded operator&, it's now just unspecified whether the overloaded operator or the builtin is used. llvm-svn: 150234
* Implement DR1458: Taking the address of an object of incomplete class type isRichard Smith2012-02-081-0/+16
| | | | | | | not a constant expression, because we can't tell whether the complete class type will have an overloaded operator&. llvm-svn: 150066
* Add more testing for r149776.Richard Smith2012-02-081-0/+85
| | | | llvm-svn: 150061
* Implement the agreed resolution to DR1457: a signed left shift of a 1 bit intoRichard Smith2012-02-081-2/+5
| | | | | | | | | | the sign bit doesn't have undefined behavior, but a signed left shift of a 1 bit out of the sign bit still does. As promised to Howard :) The suppression of the potential constant expression checking in system headers is also removed, since the problem it was working around is gone. llvm-svn: 150059
* constexpr: Fix implementation of DR1311: check for volatile qualifiers inRichard Smith2012-02-051-9/+8
| | | | | | | lvalue-to-rvalue conversions on the source type of the conversion, not the target type (which has them removed for non-class types). llvm-svn: 149796
OpenPOWER on IntegriCloud