summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/temp
Commit message (Collapse)AuthorAgeFilesLines
* [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)
* [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)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-2412-12/+12
| | | | | | | | | 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-241-1/+24
| | | | | | | | | | | | | | | | | | | | | | | 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)
* 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)
* [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
* [Concepts] Function trailing requires clausesSaar Raz2020-01-0910-42/+82
| | | | | | 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-061-0/+31
| | | | | | | | | | | | | | | | | 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.
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-234-0/+210
| | | | | | | 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-224-203/+0
| | | | | | This reverts commit d3f5769d5e93b30d4a8b4696381d5e4a304992fa. Causes crashes on Chromium. Have reproducer, will reduce and send along.
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-224-0/+203
| | | | | | | 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
* 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-184-203/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-184-0/+203
| | | | | | Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Phabricator: D41910
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-12-063-0/+202
| | | | | | | | | 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.
* [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-283-202/+0
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-253-0/+202
| | | | | | 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
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-191-0/+34
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-154-8/+106
| | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. llvm-svn: 374938
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+65
| | | | | | | | | | 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-65/+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/+65
| | | | | | 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
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-0/+39
| | | | | | | | | | | 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
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-092-5/+5
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-062-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-041-6/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-042-5/+5
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. This reinstates r354091, which was previously reverted in r354097 because it exposed bugs in lldb and compiler-rt. Those bugs were fixed in r354173 and r354174 respectively. llvm-svn: 354176
* Revert "Fix implementation of [temp.local]p4."Francis Visoiu Mistrih2019-02-151-3/+3
| | | | | | | | | This reverts commit 40bd10b770813bd1471d46f514545437516aa4ba. This seems to now emit an error when building the sanitizer tests: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53965/consoleFull. llvm-svn: 354097
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-3/+3
| | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. llvm-svn: 354091
* [NFC] Test commit: tweak whitespace in commentTan S. B.2018-12-171-2/+2
| | | | llvm-svn: 349384
* P0859R0: List-initialization is potentially-constant-evaluated andRichard Smith2018-09-261-0/+12
| | | | | | | | | | | | 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
* Improve diagnostic for missing comma in template parameter list.Richard Smith2018-08-171-3/+6
| | | | | | | | | | Given 'typename T typename U', we would correctly diagnose the missing comma, but incorrectly disambiguate the first parameter as being a non-type parameter and complain that the 'T' is not a qualified-id. See also gcc.gnu.org/PR86998. llvm-svn: 340074
* Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith2018-07-231-4/+4
| | | | | | checking. llvm-svn: 337743
* [Sema] Diagnose an invalid dependent function template specializationErik Pilkington2018-07-191-0/+28
| | | | | | | | | | | Previously, clang marked the specialization as invalid without emitting a diagnostic. This lead to an assert in CodeGen. rdar://41806724 Differential revision: https://reviews.llvm.org/D49085 llvm-svn: 337497
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-6/+6
| | | | | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. This reinstates r337226, reverted in r337255, with a fix for the InitializedEntity alignment problem that was breaking ARM buildbots. llvm-svn: 337329
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-171-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | lifetime extension." This change breaks on ARM because pointers to clang::InitializedEntity are only 4 byte aligned and do not have 3 bits to store values. A possible solution would be to change the fields in clang::InitializedEntity to enforce a bigger alignment requirement. The error message is llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer" static_assert(IntBits <= PtrTraits::NumLowBitsAvailable, include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here Value = Info::updateInt(Info::updatePointer(0, PtrVal), llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here setPointerAndInt(PtrVal, IntVal); ^ llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here return {Entity, LK_Extended}; Full log here: http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330 http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394 llvm-svn: 337255
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-6/+6
| | | | | | | | | | This change implements C++ DR1696, which makes initialization of a reference member of a class from a temporary object ill-formed. The standard wording here is imprecise, but we interpret it as meaning that any time a mem-initializer would result in lifetime extension, the program is ill-formed. llvm-svn: 337226
* PR38136: improve handling of template argument deduction of non-trailingRichard Smith2018-07-122-2/+54
| | | | | | | | | | | | | | | | | | | | | function parameter packs. This makes our handling of non-trailing function parameter packs consistent between the case of deduction at the top level in a function call and other cases where deduction encounters a non-trailing function parameter pack. Instead of treating a non-trailing pack and all later parameters as being non-deduced, we treat a non-trailing pack as exactly matching any explicitly-specified template arguments (or being an empty pack if there are no such arguments). This corresponds to the "never deduced" rule in [temp.deduct.call]p1, but generalized to all deduction contexts. Non-trailing template argument packs still result in the entire template argument list being treated as non-deduced, as specified in [temp.deduct.type]p9. llvm-svn: 336962
* Add tests for function conversions in conversion function templateRichard Smith2018-07-121-0/+17
| | | | | | deduction. llvm-svn: 336931
* Fix deduction for conversion function templates converting to referenceRichard Smith2018-07-111-0/+68
| | | | | | | | | | | | | | | | | | | types. We previously tried to use the "parameter is a reference" logic here, but that doesn't work because it gets P and A backwards. Instead, add a separate implementation of the "deduced A can be less qualified than A" rule. This also exposes that we incorrectly stripped cv-qualifiers from the referent of A if it was a reference. However, if we don't do that, we get the wrong results when P is a reference. In an attempt to match what sanity dictates and what other implementations are doing, we now remove cv-qualifiers from A and P unless both are reference types. I've brought this up on the core reflector too, to try to get the standard fixed. llvm-svn: 336867
* Fix determination of whether one set of cvr-qualifiers is compatibleRichard Smith2018-07-111-0/+10
| | | | | | | | | | with another in template argument deduction. We happened to typically get away with getting this wrong, because the cases where we'd produce a bogus deduction were caught by the final "deduced A is compatible with A" check. llvm-svn: 336852
* Parse A::template B as an identifier rather than as a template-id with noRichard Smith2018-04-271-1/+1
| | | | | | | | | | template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
* Implement C++ DR727, which permits explicit specializations at class scope.Richard Smith2018-03-165-76/+21
| | | | | | | | | More generally, this permits a template to be specialized in any scope in which it could be defined, so this also supersedes DR44 and DR374 (the latter of which we previously only implemented in C++11 mode onwards due to unclarity as to whether it was a DR). llvm-svn: 327705
* Fix a couple of cases where we would fail to correctly parse deduced class ↵Richard Smith2018-02-281-2/+2
| | | | | | | | | | | | | | | | template specialization types. Specifically, we would not properly parse these types within template arguments (for non-type template parameters), and in tentative parses. Fixing both of these essentially requires that we parse deduced template specialization types as types in all contexts, even in template argument lists -- in particular, tentative parsing may look ahead and annotate a deduced template specialization type before we figure out that we're actually supposed to treat the tokens as a template-name. We deal with this by simply permitting deduced template specialization types when parsing template arguments, and converting them to template template arguments. llvm-svn: 326299
* [Parser][FixIt] Better diagnostics for "typedef" instead of "typename" typoJan Korous2018-02-081-14/+14
| | | | | | | | rdar://problem/10214588 Differential Revision: https://reviews.llvm.org/D42170 llvm-svn: 324607
OpenPOWER on IntegriCloud