summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/drs
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-192-6/+6
| | | | | | | | | | | | | 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)
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-092-5/+41
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-092-2/+2
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* Always deduce the lengths of contained parameter packs when deducing aRichard Smith2020-01-061-2/+2
| | | | | | | | | | | | | | | | | pack expansion. Previously, if all parameter / argument pairs for a pack expansion deduction were non-deduced contexts, we would not deduce the arity of the pack, and could end up deducing a different arity (leading to failures during substitution) or defaulting to an arity of 0 (leading to bad diagnostics about passing the wrong number of arguments to a variadic function). Instead, we now always deduce the arity for all involved packs any time we deduce a pack expansion. This will result in less substitution happening in some cases, which could avoid non-SFINAEable errors, and should generally improve the quality of diagnostics when passing initializer lists to variadic functions.
* Revert "CWG2352: Allow qualification conversions during reference binding."David Blaikie2019-12-272-40/+4
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit de21704ba96fa80d3e9402f12c6505917a3885f4. Regressed/causes this to error due to ambiguity: void f(const int * const &); void f(int *); int main() { int * x; f(x); } (in case it's important - the original case where this turned up was a member function overload in a class template with, essentially: f(const T1&) f(T2*) (where T1 == X const *, T2 == X)) It's not super clear to me if this ^ is expected behavior, in which case I'm sorry about the revert & happy to look into ways to fix the original code.
* [Sema] SequenceChecker: C++17 sequencing rules for built-in operators <<, ↵Bruno Ricci2019-12-222-3/+12
| | | | | | | | | | | >>, .*, ->*, =, op= Implement the C++17 sequencing rules for the built-in operators <<, >>, .*, ->*, = and op=. Differential Revision: https://reviews.llvm.org/D58297 Reviewed By: rsmith
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2019-12-192-4/+40
| | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place.
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-242-20/+17
| | | | to the ambiguity, rather than noting all viable candidates.
* Implements CWG 1601 in [over.ics.rank/4.2]Richard Smith2019-10-062-5/+22
| | | | | | | | | | | | | | | | | | | Summary: The overload resolution for enums with a fixed underlying type has changed in the C++14 standard. This patch implements the new rule. Patch by Mark de Wever! Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65695 llvm-svn: 373866
* 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-14/+45
| | | | | | constant evaluation. llvm-svn: 372237
* [MS] Consder constexpr globals to be inline, as in C++17Reid Kleckner2019-09-111-5/+5
| | | | | | | | | | | | | | | | Summary: Microsoft seems to do this regardless of the language mode, so we must also do it in order to be ABI compatible. Fixes PR36125 Reviewers: thakis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47956 llvm-svn: 371642
* [Sema] Implement DR2386 for C++17 structured bindingReid Kleckner2019-08-151-0/+21
| | | | | | | | | | | | | | | | | | Allow implementations to provide complete definitions of std::tuple_size<T>, but to omit the 'value' member to signal that T is not tuple-like. The Microsoft standard library implements std::tuple_size<const T> this way. If the value member exists, clang still validates that it is an ICE, but if it does not, then the type is considered to not be tuple-like. Fixes PR33236 Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D66040 llvm-svn: 369043
* Fix handling of class member access into a vector type.Richard Smith2019-08-142-2/+11
| | | | | | | | | | | | | | | | | | | | | | When handling a member access into a non-class, non-ObjC-object type, we would perform a lookup into the surrounding scope as if for an unqualified lookup. If the member access was followed by a '<' and this lookup (or the typo-correction for it) found a template name, we'd treat the member access as naming that template. Now we treat such accesses as never naming a template if the type of the object expression is of vector type, so that vector component accesses are never misinterpreted as naming something else. This is not entirely correct, since it is in fact valid to name a template from the enclosing scope in this context, when invoking a pseudo-destructor for the vector type via an alias template, but that's very much a corner case, and this change leaves that case only as broken as the corresponding case for Objective-C types is. This incidentally adds support for dr2292, which permits a 'template' keyword at the start of a member access naming a pseudo-destructor. llvm-svn: 368940
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-0/+10
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. llvm-svn: 363429
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-145-7/+311
| | | | | | | | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. This reinstates r363295, reverted in r363352, with a fix for PR42276: we now produce a proper name for a non-odr-use reference to a static constexpr data member. The name <mangled-name>.const is used in that case; such names are reserved to the implementation for cases such as this and should demangle nicely. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363428
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-145-321/+7
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-0/+10
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. llvm-svn: 363337
* C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue ↵Richard Smith2019-06-135-7/+311
| | | | | | | | | | | | | | | | | | | | | conversion applied to a member access or similar not-quite-trivial lvalue expression. Summary: When a variable is named in a context where we can't directly emit a reference to it (because we don't know for sure that it's going to be defined, or it's from an enclosing function and not captured, or the reference might not "work" for some reason), we emit a copy of the variable as a global and use that for the known-to-be-read-only access. Reviewers: rjmccall Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63157 llvm-svn: 363295
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-2/+7
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. llvm-svn: 360995
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-7/+2
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) llvm-svn: 360988
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-2/+7
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) llvm-svn: 360974
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-132-5/+24
| | | | | | | | | | | | | 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-132-24/+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-132-5/+24
| | | | | | evaluation. llvm-svn: 360559
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-092-6/+72
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. llvm-svn: 360370
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-092-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-061-0/+15
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* CWG issue 727: Fix numerous bugs in support for class-scope explicitRichard Smith2019-05-031-3/+96
| | | | | | specializations for variable templates. llvm-svn: 359947
* [www] Rebuild cxx_dr_status.Richard Smith2019-04-261-1/+1
| | | | llvm-svn: 359261
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-261-0/+26
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. llvm-svn: 359260
* Add missing diagnostic for explicit instantiation declarations namingRichard Smith2019-04-261-4/+3
| | | | | | | | | | | | | | | | | internal linkage entities. Such constructs are ill-formed by [temp.explicit]p13. We make a special exception to permit an invalid construct used by libc++ in some build modes: its <valarray> header declares some functions with the internal_linkage attribute and then (meaninglessly) provides explicit instantiation declarations for them. Luckily, Clang happens to effectively ignore the explicit instantiation declaration when generating code in this case, and this change codifies that behavior. This reinstates part of r359048, reverted in r359076. (The libc++ issue triggering the rollback has been addressed.) llvm-svn: 359259
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-243-30/+5
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* Add missing diagnostic for anonymous struct/union definitions that don'tRichard Smith2019-04-243-9/+10
| | | | | | introduce any names. llvm-svn: 359051
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-233-5/+30
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* [Sema] ADL: Associated namespaces for class types and enumeration types (CWG ↵Bruno Ricci2019-04-221-0/+48
| | | | | | | | | | | | | | | | | | | 1691) CWG 1691 changed the definition of the namespaces associated with a class type or enumeration type. For a class type, the associated namespaces are the innermost enclosing namespaces of the associated classes. For an enumeration type, the associated namespace is the innermost enclosing namespace of its declaration. This also fixes CWG 1690 and CWG 1692. Differential Revision: https://reviews.llvm.org/D60573 Reviewed By: rjmccall, rsmith llvm-svn: 358882
* [Sema][NFC] Mark DR1563 as done (List-initialization and overloaded function ↵Bruno Ricci2019-04-181-0/+10
| | | | | | | | disambiguation) It has been supported since at least clang 3.1 so just mark it as done. llvm-svn: 358679
* [Sema][NFC] Mark DR705 (Suppressing argument-dependent lookup via ↵Bruno Ricci2019-04-181-0/+13
| | | | | | | | parentheses) as done It was supported since at least clang 3 so just mark it as done. llvm-svn: 358678
* Mark the lambda function pointer conversion operator as noexcept.Aaron Ballman2019-01-211-0/+12
| | | | | | This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov. llvm-svn: 351750
* PR40329: [adl] Fix determination of associated classes when searching aRichard Smith2019-01-161-0/+30
| | | | | | | | | | | | | | | | | | | | | | | member enum and then its enclosing class. There are situations where ADL will collect a class but not the complete set of associated classes / namespaces of that class. When that happened, and we later tried to collect those associated classes / namespaces, we would previously short-circuit the lookup and not find them. Eg, for: struct A : B { enum E; }; if we first looked for associated classes/namespaces of A::E, we'd find only A. But if we then tried to also collect associated classes/namespaces of A (which should include the base class B), we would not add B because we had already visited A. This also fixes a minor issue where we would fail to collect associated classes from an overloaded class member access expression naming a static member function. llvm-svn: 351382
* DR674, PR38883, PR40238: Qualified friend lookup should look for aRichard Smith2019-01-073-14/+41
| | | | | | | | | | | | | | | | | | template specialization if there is no matching non-template function. This exposed a couple of related bugs: - we would sometimes substitute into a friend template instead of a suitable non-friend declaration; this would now crash because we'd decide the specialization of the friend is a redeclaration of itself - ADL failed to properly handle the case where an invisible local extern declaration redeclares an invisible friend Both are fixed herein: in particular, we now never make invisible friends or local extern declarations visible to name lookup unless they are the only declaration of the entity. (We already mostly did this for local extern declarations.) llvm-svn: 350505
* [Sema] Produce diagnostics when C++17 aligned allocation/deallocationAkira Hatanaka2018-12-211-2/+2
| | | | | | | | | | | functions that are unavailable on Darwin are explicitly called or called from deleting destructors. rdar://problem/40736230 Differential Revision: https://reviews.llvm.org/D47757 llvm-svn: 349890
* [constexpr][c++2a] Try-catch blocks in constexpr functionsBruno Cardoso Lopes2018-12-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | 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
* Revert r345562: "PR23833, DR2140: an lvalue-to-rvalue conversion on a ↵Richard Smith2018-11-031-10/+0
| | | | | | | | | | | | glvalue of type" This exposes a (known) CodeGen bug: it can't cope with emitting lvalue expressions that denote non-odr-used but usable-in-constant-expression variables. See PR39528 for a testcase. Reverted for now until that issue can be fixed. llvm-svn: 346065
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2018-10-301-0/+10
| | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. llvm-svn: 345562
* [C++17] Reject shadowing of capture by parameter in lambdaNicolas Lesser2018-10-251-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change rejects the shadowing of a capture by a parameter in lambdas in C++17. ``` int main() { int a; auto f = [a](int a) { return a; }; } ``` results in: ``` main.cpp:3:20: error: a lambda parameter cannot shadow an explicitly captured entity auto f = [a](int a) { return a; }; ^ main.cpp:3:13: note: variable a is explicitly captured here auto f = [a](int a) { return a; }; ^ ``` Reviewers: rsmith Reviewed By: rsmith Subscribers: lebedev.ri, erik.pilkington, cfe-commits Differential Revision: https://reviews.llvm.org/D53595 llvm-svn: 345308
* [cxx2a] P0641R2: (Some) type mismatches on defaulted functions onlyRichard Smith2018-09-281-2/+2
| | | | | | | | | | | | | | | | render the function deleted instead of rendering the program ill-formed. This change also adds an enabled-by-default warning for the case where an explicitly-defaulted special member function of a non-template class is implicitly deleted by the type checking rules. (This fires either due to this language change or due to pre-C++20 reasons for the member being implicitly deleted). I've tested this on a large codebase and found only bugs (where the program means something that's clearly different from what the programmer intended), so this is enabled by default, but we should revisit this if there are problems with this being enabled by default. llvm-svn: 343285
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Warn if a local variable's initializer retains a pointer/reference to aRichard Smith2018-07-241-2/+2
| | | | | | non-lifetime-extended temporary object. llvm-svn: 337790
* Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith2018-07-232-16/+18
| | | | | | checking. llvm-svn: 337743
OpenPOWER on IntegriCloud