summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-191-36/+36
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* For P0784R7: add support for constexpr destructors, and call them asRichard Smith2019-09-231-1/+4
| | | | | | | | | | | appropriate during constant evaluation. Note that the evaluator is sometimes invoked on incomplete expressions. In such cases, if an object is constructed but we never reach the point where it would be destroyed (and it has non-trivial destruction), we treat the expression as having an unmodeled side-effect. llvm-svn: 372538
* [c++20] P1331R2: Allow transient use of uninitialized objects inRichard Smith2019-09-181-2/+8
| | | | | | constant evaluation. llvm-svn: 372237
* Implement P1668R1Erich Keane2019-08-191-2/+6
| | | | | | | Allow inline assembly statements in unexecuted branches of constexpr functions. llvm-svn: 369281
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-291-4/+1
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. llvm-svn: 367254
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-5/+17
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-17/+5
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-5/+17
| | | | | | evaluation. llvm-svn: 360559
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-101-4/+23
| | | | | | | | | | | | | | | | | | | | | | Implement support for try-catch blocks in constexpr functions, as proposed in http://wg21.link/P1002 and voted in San Diego for c++20. The idea is that we can still never throw inside constexpr, so the catch block is never entered. A try-catch block like this: try { f(); } catch (...) { } is then morally equivalent to just { f(); } Same idea should apply for function/constructor try blocks. rdar://problem/45530773 Differential Revision: https://reviews.llvm.org/D55097 llvm-svn: 348789
* [Sema] Don't crash on out-of-line virtual constexpr functionsDavid Majnemer2015-05-221-0/+4
| | | | | | | | | | The method wasn't an overrider but didn't have 'virtual' textually written because our CXXMethodDecl was an out-of-line definition. Make sure we use the canonical decl instead. This fixes PR23629. llvm-svn: 237999
* DR1684: a constexpr member function need not be a member of a literal class ↵Richard Smith2014-12-161-2/+2
| | | | | | type. llvm-svn: 224388
* C++1y is now C++14!Aaron Ballman2014-08-191-14/+14
| | | | | | Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording. llvm-svn: 215982
* C++1y: an assignment operator is implicitly 'constexpr' if it would only ↵Richard Smith2013-05-071-0/+12
| | | | | | call 'constexpr' assignment operators for a literal class type. llvm-svn: 181284
* C++1y: support 'for', 'while', and 'do ... while' in constant expressions.Richard Smith2013-05-061-8/+0
| | | | llvm-svn: 181181
* C++1y: support for increment and decrement in constant expression evaluation.Richard Smith2013-05-051-1/+1
| | | | llvm-svn: 181173
* Factor out duplication between lvalue-to-rvalue conversions and variableRichard Smith2013-05-051-4/+6
| | | | | | | assignments in constant expressions. No significant functionality changes (slight improvement to potential constant expression checking). llvm-svn: 181170
* C++1y constexpr extensions, round 1: Allow most forms of declaration andRichard Smith2013-04-221-15/+155
| | | | | | | | 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
* 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
* <rdar://problem/13584715> Converted constant expressions are expected to ↵Douglas Gregor2013-04-081-0/+16
| | | | | | | | | | | | | | have integral values. We were assuming that any expression used as a converted constant expression would either not have a folded constant value or would be an integer, which is not the case for some ill-formed constant expressions. Because converted constant expressions are only used where integral values are expected, we can simply treat this as an error path. If that ever changes, we'll need to widen the interface of Sema::CheckConvertedConstantExpression() anyway. llvm-svn: 179068
* Update constexpr implementation to match CWG's chosen approach for core issuesRichard Smith2012-02-131-14/+11
| | | | | | | | | | | | | | | | | | | | 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
* constexpr: Unlike other incomplete types, 'void' cannot possibly be completed asRichard Smith2012-02-011-0/+1
| | | | | | | a literal type. Disallow it as the return type of a constexpr function declaration. llvm-svn: 149469
* constexpr: Implement the [dcl.constexpr]p5 check for whether a constexprRichard Smith2012-01-271-0/+12
| | | | | | | function definition can produce a constant expression. This also provides the last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4. llvm-svn: 149108
* PR11754: Reject non-static constexpr member functions in classes with virtualRichard Smith2012-01-131-0/+4
| | | | | | base classes. llvm-svn: 148094
* PR11614: Mark defaulted special constructors as constexpr if their implicitRichard Smith2011-12-221-1/+1
| | | | | | definition would satisfy the constexpr requirements. llvm-svn: 147128
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-131-1/+1
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* constexpr: semantic checking for constexpr functions and constructors. Based inRichard Smith2011-10-011-0/+125
part on patches by Peter Collingbourne. We diverge from the C++11 standard in a few areas, mostly related to checking constexpr function declarations, and not just definitions. See WG21 paper N3308=11-0078 for details. Function invocation substitution is not available in this patch; constexpr functions cannot yet be used from within constant expressions. llvm-svn: 140926
OpenPOWER on IntegriCloud