summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/expr
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-281-31/+0
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-251-0/+31
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+149
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-149/+0
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+149
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* 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
* [Sema] Improved diagnostic for qualifiers in reference bindingAnastasia Stulova2019-06-212-17/+17
| | | | | | | | | Improved wording and also simplified by using printing method from qualifiers. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364023
* If capturing a variable fails, add a capture anyway (and mark itRichard Smith2019-05-281-0/+7
| | | | | | invalid) so that we can avoid repeated diagnostics for the same capture. llvm-svn: 361891
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-212-4/+64
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* 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
* [Sema] Mark array element destructors referenced during initializationErik Pilkington2019-05-101-3/+3
| | | | | | | | | | | | This fixes a crash where we would neglect to mark a destructor referenced for an __attribute__((no_destory)) array. The destructor is needed though, since if an exception is thrown we need to cleanup the elements. rdar://48462498 Differential revision: https://reviews.llvm.org/D61165 llvm-svn: 360446
* Mark the lambda function pointer conversion operator as noexcept.Aaron Ballman2019-01-211-0/+8
| | | | | | This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov. llvm-svn: 351750
* 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
* [Sema] Remove location from implicit capture init exprVedant Kumar2018-09-132-4/+4
| | | | | | | | | | | | | | | | | | A lambda's closure is initialized when the lambda is declared. For implicit captures, the initialization code emitted from EmitLambdaExpr references source locations *within the lambda body* in the function containing the lambda. This results in a poor debugging experience: we step to the line containing the lambda, then into lambda, out again, over and over, until every capture's field is initialized. To improve stepping behavior, assign the starting location of the lambda to expressions which initialize an implicit capture within it. rdar://39807527 Differential Revision: https://reviews.llvm.org/D50927 llvm-svn: 342194
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
* [C++17] Disallow lambdas in template parameters (PR33696).Nicolas Lesser2018-07-121-0/+7
| | | | | | | | | | | | | | Summary: This revision disallows lambdas in template parameters, as reported in PR33696. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D37442 llvm-svn: 336930
* Fix determination of whether a reinterpret_cast casts away constness.Richard Smith2018-07-101-0/+26
| | | | | | | | | | | | | | The "casts away constness" check doesn't care at all how the different layers of the source and destination type were formed: for example, if the source is a pointer and the destination is a pointer-to-member, the types are still decomposed and their pointee qualifications are still checked. This rule is bizarre and somewhat ridiculous, so as an extension we accept code making use of such reinterpret_casts with a warning outside of SFINAE contexts. llvm-svn: 336738
* PR37450: Fix bug that disabled some type checks for variables with deduced ↵Richard Smith2018-05-141-2/+10
| | | | | | | | types. Also improve diagnostic for the case where a type is non-literal because it's a lambda. llvm-svn: 332286
* P0620 follow-up: deducing `auto` from braced-init-list in new exprZhihao Yuan2017-12-113-2/+25
| | | | | | | | | | | | | | | | | | | Summary: This is a side-effect brought in by p0620r0, which allows other placeholder types (derived from `auto` and `decltype(auto)`) to be usable in a `new` expression with a single-clause //braced-init-list// as its initializer (8.3.4 [expr.new]/2). N3922 defined its semantics. References: http://wg21.link/p0620r0 http://wg21.link/n3922 Reviewers: rsmith, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D39451 llvm-svn: 320401
* 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
* [c++2a] Implement P0409R2 - Allow lambda capture [=,this] (by hamzasood)Faisal Vali2017-08-191-2/+2
| | | | | | | | | | This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency. https://reviews.llvm.org/D36572 Thanks Hamza! llvm-svn: 311224
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-1/+1
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] P0091R3: Basic support for deducing class template arguments via ↵Richard Smith2017-02-091-0/+10
| | | | | | deduction-guides. llvm-svn: 294613
* [Sema] Add warning for unused lambda capturesMalcolm Parsons2017-01-135-5/+5
| | | | | | | | | | | | | | | Summary: Warn when a lambda explicitly captures something that is not used in its body. The warning is part of -Wunused and can be enabled with -Wunused-lambda-capture. Reviewers: rsmith, arphaman, jbcoe, aaron.ballman Subscribers: Quuxplusone, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D28467 llvm-svn: 291905
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | operands where possible. This implements something like the current direction of DR1581: we use a narrow syntactic check to determine the set of places where a constant expression could be evaluated, and only instantiate a constexpr function or variable if it's referenced in one of those contexts, or is odr-used. It's not yet clear whether this is the right set of syntactic locations; we currently consider all contexts within templates that would result in odr-uses after instantiation, and contexts within list-initialization (narrowing conversions take another victim...), as requiring instantiation. We could in principle restrict the former cases more (only const integral / reference variable initializers, and contexts in which a constant expression is required, perhaps). However, this is sufficient to allow us to accept libstdc++ code, which relies on GCC's behavior (which appears to be somewhat similar to this approach). llvm-svn: 291318
* [c++1z] When initializing a const-qualified class type, don't forget to add onRichard Smith2016-12-211-0/+10
| | | | | | | the requested cv-qualifiers after construction. This usually doesn't matter, but it does matter within a ?: operator. llvm-svn: 290227
* [c++1z] P0003R5: Removing dynamic exception specifications.Richard Smith2016-12-081-1/+1
| | | | | | | | | | | | | | | | | | We continue to support dynamic exception specifications in C++1z as an extension, but produce an error-by-default warning when we encounter one. This allows users to opt back into the feature with a warning flag, and implicitly opts system headers back into the feature should they happen to use it. There is one semantic change implied by P0003R5 but not implemented here: violating a throw() exception specification should now call std::terminate directly instead of calling std::unexpected(), but since P0003R5 also removes std::unexpected() and std::set_unexpected, and the default unexpected handler calls std::terminate(), a conforming C++1z program cannot tell that we are still calling it. The upside of this strategy is perfect backwards compatibility; the downside is that we don't get the more efficient 'noexcept' codegen for 'throw()'. llvm-svn: 289019
* 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
* PR23281: Fix implementation of DR1891 to implement the intent: that is, aRichard Smith2016-11-161-2/+2
| | | | | | lambda-expression does not have a move-assignment operator. llvm-svn: 287057
* [Sema] Allow static_cast<T&&>(e) to check explicit conversions for ↵Eric Fiselier2016-11-031-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-reference-related types. Summary: [expr.cast.static] states: > 3. A glvalue of type “cv1 T1” can be cast to type “rvalue reference to cv2 T2” if “cv2 T2” is reference-compatible > with “cv1 T1”. The result refers to the object or the specified base class subobject thereof. If T2 is > an inaccessible or ambiguous base class of T1, a program that necessitates such a cast is > ill-formed. > > 4. Otherwise, an expression e can be explicitly converted to a type T using a static_cast of the form static_- > cast<T>(e) if the declaration T t(e); is well-formed, for some invented temporary variable t. [...] Currently when checking p3 Clang will diagnose `static_cast<T&&>(e)` as invalid if the argument is not reference compatible with `T`. However I believe the correct behavior is to also check p4 in those cases. For example: ``` double y = 42; static_cast<int&&>(y); // this should be OK. 'int&& t(y)' is well formed ``` Note that we still don't check p4 for non-reference-compatible types which are reference-related since `T&& t(e);` should never be well formed in those cases. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26231 llvm-svn: 285872
* [c++1z] P0012R1: Implement a few remaining pieces: downgrade diagnostic forRichard Smith2016-10-222-4/+14
| | | | | | | | | | | | | | mismatched dynamic exception specifications in expressions from an error to a warning, since this is no longer ill-formed in C++1z. Allow reference binding of a reference-to-non-noexcept function to a noexcept function lvalue. As defect resolutions, also allow a conditional between noexcept and non-noexcept function lvalues to produce a non-noexcept function lvalue (rather than decaying to a function pointer), and allow function template argument deduction to deduce a reference to non-noexcept function when binding to a noexcept function type. llvm-svn: 284905
* 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
* Re-commit r284753, reverted in r284778, with a fix for PR30749.Richard Smith2016-10-201-0/+51
| | | | | | | | | | Original commit message: [c++1z] Teach composite pointer type computation how to compute the composite pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284785
* Revert r284753 "[c++1z] Teach composite pointer type computation how to ↵Hans Wennborg2016-10-201-45/+0
| | | | | | | | compute the composite" It caused PR30749. llvm-svn: 284778
* [c++1z] Teach composite pointer type computation how to compute the compositeRichard Smith2016-10-201-0/+45
| | | | | | | pointer type of two function pointers with different noexcept specifications. While I'm here, also teach it how to merge dynamic exception specifications. llvm-svn: 284753
* P0012R1: Make exception specifications be part of the type system. ThisRichard Smith2016-10-162-2/+23
| | | | | | | implements the bulk of the change (modifying the type system to include exception specifications), but not all the details just yet. llvm-svn: 284337
* Re-commit r283722, reverted in r283750, with a fix for a CUDA-specific use ofRichard Smith2016-10-103-1/+150
| | | | | | | | | | | past-the-end iterator. Original commit message: P0035R4: Semantic analysis and code generation for C++17 overaligned allocation. llvm-svn: 283789
* Revert "P0035R4: Semantic analysis and code generation for C++17 overaligned ↵Daniel Jasper2016-10-103-150/+1
| | | | | | | | | | | | allocation." This reverts commit r283722. Breaks: Clang.SemaCUDA.device-var-init.cu Clang.CodeGenCUDA.device-var-init.cu http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/884/ llvm-svn: 283750
* P0035R4: Semantic analysis and code generation for C++17 overalignedRichard Smith2016-10-103-1/+150
| | | | | | allocation. llvm-svn: 283722
* Warn when a reference is bound to an empty l-value (dereferenced null pointer).Nick Lewycky2016-05-141-2/+2
| | | | llvm-svn: 269572
* [Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3)Faisal Vali2016-03-211-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement lambda capture of *this by copy. For e.g.: struct A { int d = 10; auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; } }; auto L = A{}.foo(); // A{}'s lifetime is gone. // Below is still ok, because *this was captured by value. assert(L(10) == 20); assert(L(100) == 120); If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined. Implementation Strategy: - amend the parser to accept *this in the lambda introducer - add a new king of capture LCK_StarThis - teach Sema::CheckCXXThisCapture to handle by copy captures of the enclosing object (i.e. *this) - when CheckCXXThisCapture does capture by copy, the corresponding initializer expression for the closure's data member direct-initializes it thus making a copy of '*this'. - in codegen, when assigning to CXXThisValue, if *this was captured by copy, make sure it points to the corresponding field member, and not, unlike when captured by reference, what the field member points to. - mark feature as implemented in svn Much gratitude to Richard Smith for his carefully illuminating reviews! llvm-svn: 263921
* 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
OpenPOWER on IntegriCloud