summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-198-82/+82
| | | | | | | | | | | | | 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)
* [Concepts] Do not check constraints if not all template arguments have been ↵Saar Raz2020-02-121-0/+6
| | | | | | | | | | | | | deduced We previously checked the constraints of instantiated function templates even in cases where PartialOverloading was true and not all template arguments have been deduced, which caused crashes in clangd (bug 44714). We now check if all arguments have been deduced before checking constraints in partial overloading scenarios. (cherry picked from commit 5fef14d932fe602bf998b8fb8a809ff85ca1e245)
* PR44721: Don't consider overloaded operators for built-in comparisonsRichard Smith2020-02-041-0/+12
| | | | | | | | | | | | | | | | | | | | when building a defaulted comparison. As a convenient way of asking whether `x @ y` is valid and building it, we previouly always performed overload resolution and built an overloaded expression, which would both end up picking a builtin operator candidate when given a non-overloadable type. But that's not quite right, because it can result in our finding a user-declared operator overload, which we should never do when applying operators non-overloadable types. Handle this more correctly: skip overload resolution when building `x @ y` if the operands are not overloadable. But still perform overload resolution (considering only builtin candidates) when checking validity, as we don't have any other good way to ask whether a binary operator expression would be valid. (cherry picked from commit 1f3f8c369a5067a132c871f33a955a7feaea8534)
* PR44761: Fix fallback to later tiebreakers if two non-template functionsRichard Smith2020-02-041-0/+16
| | | | | | are equally constrained. (cherry picked from commit cfacf9ae20b8c97a428f118a2720bc109ba6a143)
* PR44723: Trigger return type deduction for operator<=>s whose returnRichard Smith2020-01-311-0/+33
| | | | | | | | | | types are needed to compute the return type of a defaulted operator<=>. This raises the question of what to do if return type deduction fails. The standard doesn't say, and implementations vary, so for now reject that case eagerly to keep our options open. (cherry picked from commit 42d4a55f227a1cc78ab8071062d869abe88655d9)
* [Concepts] Correctly form initial parameter mapping for parameter packs, ↵Saar Raz2020-01-311-0/+51
| | | | | | | | | | | | support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent). (cherry picked from commit ba1f3db4b0729ad932aa4f091e9578132d98a0c8)
* PR44627: Consider reversing == and <=> candidates found by ADL.Richard Smith2020-01-302-1/+13
| | | | (cherry picked from commit 1db66e705f4dbe7dbe17edac804289ef59d5f616)
* [Concepts] Check function constraints before deducing auto return typeSaar Raz2020-01-311-0/+3
| | | | | | | | | | A constrained function with an auto return type would have it's definition instantiated in order to deduce the auto return type before the constraints are checked. Move the constraints check after the return type deduction. (cherry picked from commit 980517b3530ffb7faa1a23fdc007d78f5b45ae3c)
* [Concept] Fix incorrect check for containsUnexpandedParameterPack in CSESaar Raz2020-01-301-0/+15
| | | | | | | | | | We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
* [Concepts] Make constraint expressions unevaluated until satisfaction checkingSaar Raz2020-01-241-2/+3
| | | | | | | | | As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic constraints only become constant evaluated during satisfaction checking. Change the evaluation context during parsing and instantiation of constraints to unevaluated. (cherry picked from commit 73eaf62463b4a29adf4194685af12d1a5d172987)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-2430-32/+31
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* [Concepts] Implement P1616R1 - Using unconstrained template template ↵Saar Raz2020-01-241-5/+5
| | | | | | | | | | | | | | | | parameters with constrained templates Summary: Allow unconstrained template template parameters to accept constrainted templates as arguments. Reviewers: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73155 (cherry picked from commit d42d5eb8ea77b3a3a502a60ba3f053fb81a897f3)
* [Concepts] Placeholder constraints and abbreviated templatesSaar Raz2020-01-244-4/+331
| | | | | | | | | | | | | | | | | | | | | | | This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042 (cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
* [Concepts] Profile TypeConstraints in ProfileTemplateParameterListSaar Raz2020-01-241-0/+17
| | | | | | | | | | | Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish between partial specializations which differ in their TemplateParameterList type constraints. Recommit, now profiling the IDC so that we can deal with situations where the TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints). (cherry picked from commit 62c221b5090c2e1d3ca408bcab6f69c4d9e175b7)
* [Concepts] Requires ExpressionsSaar Raz2020-01-247-0/+751
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith2020-01-241-1/+1
| | | | | | | | | | | | | | A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state. (cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
* PR44540: Prefer an inherited default constructor over an initializerRichard Smith2020-01-141-0/+14
| | | | | | | | | list constructor when initializing from {}. We would previously pick between calling an initializer list constructor and calling a default constructor unstably in this situation, depending on whether the inherited default constructor had already been used elsewhere in the program.
* [Concepts] Type ConstraintsSaar Raz2020-01-154-1/+198
| | | | | | | Add support for type-constraints in template type parameters. Also add support for template type parameters as pack expansions (where the type constraint can now contain an unexpanded parameter pack). Differential Revision: https://reviews.llvm.org/D44352
* 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-098-10/+10
| | | | | | | | | | | | | | 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.
* [Concepts] Fix failing test on WindowsSaar Raz2020-01-091-3/+2
| | | | Fix test failed by D43357 on Windows.
* [Concepts] Function trailing requires clausesSaar Raz2020-01-0918-42/+472
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* Always deduce the lengths of contained parameter packs when deducing aRichard Smith2020-01-062-2/+33
| | | | | | | | | | | | | | | | | 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.
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-235-5/+220
| | | | | | | Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
* Revert "[Concepts] Constrained partial specializations and function overloads."Reid Kleckner2019-12-225-213/+5
| | | | | | This reverts commit d3f5769d5e93b30d4a8b4696381d5e4a304992fa. Causes crashes on Chromium. Have reproducer, will reduce and send along.
* [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
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-225-5/+213
| | | | | | | Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing some crashes and warnings. Differential Revision: https://reviews.llvm.org/D41910
* 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.
* Fix crash on init-capture packs where the type of the initializer is ↵Richard Smith2019-12-191-0/+8
| | | | non-dependent.
* Revert concepts changes from D41910Vedant Kumar2019-12-185-213/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These changes caused LibcxxVariantDataFormatterTestCase in lldb to fail with an assert: Assertion failed: (Idx < size() && "Out-of-bounds Bit access."), function operator[], file /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/ADT/SmallBitVector.h, line 452. In: 7 clang-10 0x00000001094b79d9 isAtLeastAsSpecializedAs(clang::Sema&, clang::SourceLocation, clang::FunctionTemplateDecl*, clang::FunctionTemplateDecl*, clang::TemplatePartialOrderingContext, unsigned int) + 1865 8 clang-10 0x00000001094b7111 clang::Sema::getMoreSpecializedTemplate(clang::FunctionTemplateDecl*, clang::FunctionTemplateDecl*, clang::SourceLocation, clang::TemplatePartialOrderingContext, unsigned int, unsigned int) + 97 9 clang-10 0x000000010939bf88 clang::isBetterOverloadCandidate(clang::Sema&, clang::OverloadCandidate const&, clang::OverloadCandidate const&, clang::SourceLocation, clang::OverloadCandidateSet::CandidateSetKind) + 1128 Revert "[Concepts] Fix incorrect move out of temporary in D41910" This reverts commit 11d5fa6e87e3584f72056ecc2b17f88c58323dde. Revert "[Concepts] Fix crash in D41910" This reverts commit 12038be20ee6a903cdbd3fddce65535ef683e31d. Revert "[Concepts] Constrained partial specializations and function overloads." This reverts commit fc0731b98a67c793862288f8ae334322666214dc.
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-185-5/+213
| | | | | | Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Phabricator: D41910
* 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.
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-161-0/+52
| | | | | | | | | | | | | | | | | | | This covers: * usual arithmetic conversions (comparisons, arithmetic, conditionals) between different enumeration types * usual arithmetic conversions between enums and floating-point types * comparisons between two operands of array type The deprecation warnings are on-by-default (in C++20 compilations); it seems likely that these forms will become ill-formed in C++23, so warning on them now by default seems wise. For the first two bullets, off-by-default warnings were also added for all the cases where we didn't already have warnings (covering language modes prior to C++20). These warnings are in subgroups of the existing -Wenum-conversion (except that the first case is not warned on if either enumeration type is anonymous, consistent with our existing -Wenum-conversion warnings).
* [c++20] Compute exception specifications for defaulted comparisons.Richard Smith2019-12-153-10/+236
| | | | | | | | This requires us to essentially fully form the body of the defaulted comparison, but from an unevaluated context. Naively this would require generating the function definition twice; instead, we ensure that the function body is implicitly defined before performing the check, and walk the actual body where possible.
* [c++20] Implement P1946R0: allow defaulted comparisons to take theirRichard Smith2019-12-102-4/+28
| | | | arguments by value.
* [c++20] Delete defaulted comparison functions if they would invoke anRichard Smith2019-12-103-0/+98
| | | | inaccessible comparison function.
* [c++20] Implement P1185R2 (as modified by P2002R0).Richard Smith2019-12-101-0/+146
| | | | | | For each defaulted operator<=> in a class that doesn't explicitly declare any operator==, also inject a matching implicit defaulted operator==.
* [c++20] Return type deduction for defaulted three-way comparisons.Richard Smith2019-12-101-0/+125
|
* [c++20] Fix handling of unqualified lookups from a defaulted comparisonRichard Smith2019-12-091-0/+76
| | | | | | | | | | function. We need to perform unqualified lookups from the context of a defaulted comparison, but not until we implicitly define the function, at which point we can't do those lookups any more. So perform the lookup from the end of the class containing the =default declaration and store the lookup results on the defaulted function until we synthesize the body.
* [c++20] Defaulted comparison support for array members.Richard Smith2019-12-095-37/+92
|
* [c++20] Synthesis of defaulted comparison functions.Richard Smith2019-12-087-20/+222
| | | | | | Array members are not yet handled. In addition, defaulted comparisons can't yet find comparison operators by unqualified lookup (only by member lookup and ADL). These issues will be fixed in follow-on changes.
* [c++20] Determine whether a defaulted comparison should be deleted orRichard Smith2019-12-067-47/+502
| | | | constexpr.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-12-064-0/+233
| | | | | | | | | 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 Re-commit, after fixing some memory bugs.
* [Diagnostics] Try to improve warning message for -Wreturn-typeDávid Bolvanský2019-11-092-2/+2
| | | | | | | | | | | | | | Summary: I agree with https://easyaspi314.github.io/gcc-vs-clang.html?fbclid=IwAR1VA0qxiWVUusOQUv5z7JESS7ZpeJy-UqAI5mnJscofGLqXcqeErIUB2gU, current warning message is not very good. We should try to improve it.. Reviewers: rsmith, aaron.ballman, easyaspi314 Reviewed By: aaron.ballman Subscribers: arphaman, Quuxplusone, mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69762
* [Sema] Fixes templated friend member assertionMark de Wever2019-11-051-1/+10
| | | | | | Fixes PR41792: Clang assertion failure on templated friend member function Differential Revision: https://reviews.llvm.org/D69481
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-284-233/+0
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [c++20] Enforce rule that a union-like class or class with referenceRichard Smith2019-10-271-0/+70
| | | | members cannot have defaulted comparisons.
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-247-40/+37
| | | | to the ambiguity, rather than noting all viable candidates.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-254-0/+233
| | | | | | 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
OpenPOWER on IntegriCloud