summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace remaining user-visible mentions of C++1z with C++17.Richard Smith2017-08-131-1/+1
| | | | llvm-svn: 310804
* Regression test for PR10856Serge Pavlov2017-07-261-0/+49
| | | | llvm-svn: 309118
* Fix test case in pre-C++11 mode; address Aaron Ballman's code review.Douglas Gregor2017-07-051-1/+1
| | | | llvm-svn: 307202
* Cope with Range-v3's CONCEPT_REQUIRES idiomDouglas Gregor2017-07-051-0/+26
| | | | llvm-svn: 307197
* Customize the SFINAE diagnostics for enable_if to provide the failed condition.Douglas Gregor2017-07-052-5/+5
| | | | | | | | | | | | | | | | | | | | When enable_if disables a particular overload resolution candidate, rummage through the enable_if condition to find the specific condition that caused the failure. For example, if we have something like: template< typename Iter, typename = std::enable_if_t<Random_access_iterator<Iter> && Comparable<Iterator_value_type<Iter>>>> void mysort(Iter first, Iter last) {} and we call "mysort" with "std::list<int>" iterators, we'll get a diagnostic saying that the "Random_access_iterator<Iter>" requirement failed. If we call "mysort" with "std::vector<something_not_comparable>", we'll get a diagnostic saying that the "Comparable<...>" requirement failed. llvm-svn: 307196
* Fix PR 33189: Clang assertion on template destructor declarationHubert Tong2017-06-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch aims to fix the bug reported at https://bugs.llvm.org/show_bug.cgi?id=33189. Clang hits an assertion when a template destructor declaration is present. This is caused by later processing that does not expect to encounter a template when looking at a destructor. The resolution is to treat the destructor as being not declared when later processing is interested in the properties of the destructor of a class. Reviewers: rcraik, hubert.reinterpretcast, aaron.ballman, rsmith Reviewed By: rsmith Subscribers: rsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D33833 Patch by Kuang He! llvm-svn: 306905
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-071-0/+54
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
* Improve error recovery for missing 'template' keyword in contexts where theRichard Smith2017-06-071-0/+22
| | | | | | | | | | | | | | template is valid with or without it (with different meanings). If we see "dependent.x<...", and what follows the '<' is a valid expression, we must parse the '<' as a comparison rather than a template angle bracket. When we later come to instantiate, if we find that the LHS of the '<' actually names an overload set containing function templates, produce a diagnostic suggesting that the 'template' keyword was missed rather than producing a mysterious diagnostic saying that the function must be called (and pointing at what looks to already be a function call!). llvm-svn: 304852
* PR33318: Add missing full-expression checking to static_assert expression.Richard Smith2017-06-061-3/+3
| | | | | | | This fixes missing lambda-captures for variables referenced only inside a static_assert (!), among other things. llvm-svn: 304760
* Fix assertion failure if we can't deduce a template argument for a variableRichard Smith2017-06-021-17/+19
| | | | | | | | | | | | template partial specialization. In passing, fix the deduction-crash.cpp test to actually run all the tests. Due to a typo, the last third of the file was being skipped by the parser and some of the tests were not actually testing anything as a result. Switch from FileCheck to -verify to make the problem more obvious and prevent this happening again. llvm-svn: 304604
* Improve diagnosis of unknown template name.Richard Smith2017-05-103-4/+3
| | | | | | | | | When an undeclared identifier in a context that requires a type is followed by '<', only look for type templates when typo-correcting, tweak the diagnostic text to say that a template name (not a type name) was undeclared, and parse the template arguments when recovering from the error. llvm-svn: 302732
* When we see a '<' operator, check whether it's a probable typo for a ↵Richard Smith2017-05-101-0/+43
| | | | | | | | | | | | | | | | | | | template-id. The heuristic that we use here is: * the left-hand side must be a simple identifier or a class member access * the right-hand side must be '<' followed by either a '>' or by a type-id that cannot be an expression (in particular, not followed by '(' or '{') * there is a '>' token matching the '<' token The second condition guarantees the expression would otherwise be ill-formed. If we're confident that the user intended the name before the '<' to be interpreted as a template, diagnose the fact that we didn't interpret it that way, rather than diagnosing that the template arguments are not valid expressions. llvm-svn: 302615
* When instantiating a friend function template, don't forget to inherit ↵Richard Smith2017-05-101-0/+16
| | | | | | default template arguments from other declarations. llvm-svn: 302603
* Don't mark a member as a member specialization until we know we're keeping ↵Richard Smith2017-05-091-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | the specialization. This improves our behavior in a few ways: * We now guarantee that if a member is marked as being a member specialization, there will actually be a member specialization declaration somewhere on its redeclaration chain. This fixes a crash in modules builds where we would try to check that there was a visible declaration of the member specialization and be surprised to not find any declaration of it at all. * We don't set the source location of the in-class declaration of the member specialization to the out-of-line declaration's location until we have actually finished merging them. This fixes some very silly looking diagnostics, where we'd point a "previous declaration is here" note at the same declaration we're complaining about. Ideally we wouldn't mess with the prior declaration's location at all, but too much code assumes that the first declaration of an entity is a reasonable thing to use as an indication of where it was declared, and that's not really true for a member specialization unless we fake it like this. llvm-svn: 302596
* Revert "Address http://bugs.llvm.org/pr30994 so that a non-friend can ↵Benjamin Kramer2017-04-171-13/+13
| | | | | | | | | properly replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp." This reverts commit r300443. Breaks compiling libc++ with modules in some configurations. llvm-svn: 300497
* Address http://bugs.llvm.org/pr30994 so that a non-friend can properly ↵Yaron Keren2017-04-171-13/+13
| | | | | | | | | | | | replace a friend, and a visible friend can properly replace an invisible friend but not vice verse, and definitions are not replaced. This fixes the two FIXME in SemaTemplate/friend-template.cpp. The code implements Richard Smith suggestion in comment 3 of the PR. reviewer: Vassil Vassilev Differential Revision: https://reviews.llvm.org/D31540 llvm-svn: 300443
* PR32185: Revert r291512 and add a testcase for PR32185.Richard Smith2017-04-133-16/+50
| | | | | | | | | | | | | | | This reverts an attempt to check that types match when matching a dependently-typed non-type template parameter. (This comes up when matching the parameters of a template template parameter against the parameters of a template template argument.) The matching rules here are murky at best. Our behavior after this revert is definitely wrong for certain C++17 features (for 'auto' template parameter types within the parameter list of a template template argument in particular), but our behavior before this revert is wrong for some pre-existing testcases, so reverting to our prior behavior seems like our best option. llvm-svn: 300262
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-102-2/+2
| | | | | | | | | | | | Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 llvm-svn: 297465
* [Test] Make Lit tests C++11 compatible #9Charles Li2017-02-243-5/+54
| | | | | | | | [Test] Make Lit tests C++11 compatible #9 Differential Revision: https://reviews.llvm.org/D20710 llvm-svn: 296184
* Recently a change was made to this test in r294639 which fails when theDouglas Yung2017-02-241-1/+6
| | | | | | | | | | | compiler is run in a mode where the default C++ standard is newer than C++03. The reason is because one of the warnings checked is only produced when the compiler is using C++03 or lower. This change fixes this problem as well as adds explicit run lines to run the test in C++03 and C++11 modes. llvm-svn: 296066
* Improve support for 'decltype(auto)' in template template parameter matching.Richard Smith2017-02-221-6/+7
| | | | | | | | | | | | | | | A 'decltype(auto)' parameter can match any other kind of non-type template parameter, so should be usable in place of any other parameter in a template template argument. The standard is sadly extremely unclear on how this is supposed to work, but this seems like the obviously-correct result. It's less clear whether an 'auto' parameter should be able to match 'decltype(auto)', since the former cannot be used if the latter turns out to be used for a reference type, but if we disallow that then consistency suggests we should also disallow 'auto' matching 'T' for the same reason, defeating intended use cases of the feature. llvm-svn: 295866
* Fix deduction of type of pack-expanded non-type template parameter.Richard Smith2017-02-211-3/+7
| | | | | | | | | We need to look through the PackExpansionType in the parameter type when deducing, and we need to consider the possibility of deducing arguments for packs that are not lexically mentioned in the pattern (but are nonetheless deducible) when figuring out which packs are covered by a pack deduction scope. llvm-svn: 295790
* When deducing an array bound from the length of an initializer list, don'tRichard Smith2017-02-211-0/+42
| | | | | | assume the bound has a non-dependent integral type. llvm-svn: 295698
* PR32010: Fix template argument depth mixup when forming implicit constructorRichard Smith2017-02-211-0/+13
| | | | | | | | | | | | | template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
* Add template parameter depth and index to -ast-dump output.Richard Smith2017-02-211-1/+1
| | | | llvm-svn: 295689
* Revert r295277 to fix buildbot.Richard Smith2017-02-164-47/+15
| | | | llvm-svn: 295281
* Add missing "deduced A == A" check for function template partial ordering.Richard Smith2017-02-164-15/+47
| | | | | | | | | This appears to be the only template argument deduction context where we were missing this check. Surprisingly, other implementations also appear to miss the check in this case; it may turn out that important code is relying on the widespread non-conformance here, in which case we'll need to reconsider. llvm-svn: 295277
* Speculatively revert r295118 to see if it's what's causing the modules ↵Richard Smith2017-02-151-11/+0
| | | | | | selfhost buildbots to fail. llvm-svn: 295146
* Do not implicitly instantiate the definition of a class template specializationRichard Smith2017-02-141-0/+11
| | | | | | | | | | | | | | | that has been explicitly specialized! We assume in various places that we can tell the template specialization kind of a class type by looking at the declaration produced by TagType::getDecl. That was previously not quite true: for an explicit specialization, we could have first seen a template-id denoting the specialization (with a use that does not trigger an implicit instantiation of the defintiion) and then seen the first explicit specialization declaration. TagType::getDecl would previously return an arbitrary declaration when called on a not-yet-defined class; it now consistently returns the most recent declaration in that case. llvm-svn: 295118
* Diagnose attempts to explicitly instantiate a template at class scope. ↵Richard Smith2017-02-092-4/+8
| | | | | | Previously Clang would simply ignore the 'template' keyword in this case. llvm-svn: 294639
* [Lit Test] Make tests C++11 compatible - Microsoft diagnosticsCharles Li2017-02-061-4/+50
| | | | | | Differential Revision: https://reviews.llvm.org/D29520 llvm-svn: 294225
* -Wunused-func-template: do not warn on non-template function declarations thatRichard Smith2017-01-281-0/+8
| | | | | | | were nonetheless instantiated (particularly, non-template friends declared within class templates). llvm-svn: 293358
* When converting a template argument representing &array to an expression for aRichard Smith2017-01-281-0/+8
| | | | | | | pointer typed template parameter, form &array rather than an array-to-pointer decay on array. llvm-svn: 293350
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-262-2/+3
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-194-6/+10
| | | | | | | | | | | | | | | | | | | | | | Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. llvm-svn: 292518
* Partial revert of r290511.Richard Smith2017-01-174-18/+32
| | | | | | | | | | | | | | | | The rules around typechecking deduced template arguments during partial ordering are not clear, and while the prior behavior does not seem to be correct (it doesn't follow the general model of partial ordering where each template parameter is replaced by a non-dependent but unique value), the new behavior is also not clearly right and breaks some existing idioms. The new behavior is retained for dealing with non-type template parameters with 'auto' types, as without it even the most basic uses of that feature don't work. We can revisit this once CWG has come to an agreement on how partial ordering with 'auto' non-type template parameters is supposed to work. llvm-svn: 292183
* Give more accurate descriptions of what kind of template we found in ↵Richard Smith2017-01-141-0/+11
| | | | | | | | | diagnostics. We were previouly assuming that every type template was a class template, which is not true any more. llvm-svn: 291988
* PR31606: Generalize our tentative DR resolution for inheriting copy/moveRichard Smith2017-01-131-3/+3
| | | | | | constructors to better match the pre-P0136R1 behavior. llvm-svn: 291955
* Don't try to check implicit conversion sequences for an object argument ifRichard Smith2017-01-101-3/+14
| | | | | | | there is no object argument, when early checking of implicit conversion sequences for a function template fails. llvm-svn: 291597
* Fix conversion index / argument index mismatch when diagnosing overload ↵Richard Smith2017-01-101-0/+6
| | | | | | resolution failure. llvm-svn: 291596
* Check that template template arguments match template template parametersRichard Smith2017-01-092-6/+29
| | | | | | | | | | | | | | | properly even when a non-type template parameter has a dependent type. Previously, if a non-type template parameter was dependent, but not dependent on an outer level of template parameter, we would not match the type of the parameter. Under [temp.arg.template], we are supposed to check that the types are equivalent, which means checking for syntactic equivalence in the dependent case. This also fixes some accepts-invalids when passing templates with auto-typed non-type template parameters as template template arguments. llvm-svn: 291512
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-092-2/+10
| | | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811 and r291412, with a couple of fixes for handling of explicitly-specified non-trailing template argument packs. llvm-svn: 291427
* Implement DR1388 (wg21.link/cwg1388).Richard Smith2017-01-091-3/+21
| | | | | | | | | | | | This issue clarifies how deduction proceeds past a non-trailing function parameter pack. Essentially, the pack itself is skipped and consumes no arguments (except for those implied by an explicitly-specified template arguments), and nothing is deduced from it. As a small fix to the standard's rule, we do not allow subsequent deduction to change the length of the function parameter pack (by preventing extension of the explicitly-specified pack if present, and otherwise deducing all contained packs to empty packs). llvm-svn: 291425
* Revert r291410 and r291411.Richard Smith2017-01-091-6/+2
| | | | | | The test-suite bots are still failing even after r291410's fix. llvm-svn: 291412
* Implement C++ DR1391 (wg21.link/cwg1391)Richard Smith2017-01-091-2/+6
| | | | | | | | | | | | | Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on the basis that substitution failure outside the immediate context is much more common during substitution than during implicit conversion sequence formation. This re-commits r290808, reverted in r290811, with a fix for handling of explicitly-specified template argument packs. llvm-svn: 291410
* PR31514: Add recursive self-instantiation check during template argumentRichard Smith2017-01-082-1/+11
| | | | | | | | | | | deduction in partial ordering. This prevents us from crashing due to attempting to instantiate the same class template specialization definition multiple times. (Debug builds also appear to sometimes hit the stack limit before hitting the instantiation depth limit in this case.) llvm-svn: 291407
* PR20090: Add (passing) test from this bug; it's been fixed for a while.Richard Smith2017-01-071-0/+7
| | | | llvm-svn: 291319
* PR23135: Don't instantiate constexpr functions referenced in unevaluated ↵Richard Smith2017-01-073-22/+67
| | | | | | | | | | | | | | | | | | | | | 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
* If an explicitly-specified pack might have been extended by template argumentRichard Smith2017-01-051-0/+14
| | | | | | deduction, don't forget to check the argument is valid. llvm-svn: 291170
* Per [temp.deduct.call], do not deduce an array bound of 0 from an empty ↵Richard Smith2017-01-051-0/+14
| | | | | | initializer list. llvm-svn: 291075
OpenPOWER on IntegriCloud