summaryrefslogtreecommitdiffstats
path: root/clang/test/SemaTemplate/class-template-spec.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Implement C++ DR727, which permits explicit specializations at class scope.Richard Smith2018-03-161-8/+2
| | | | | | | | | 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
* Partial revert of r290511.Richard Smith2017-01-171-6/+6
| | | | | | | | | | | | | | | | 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
* DR1315: a non-type template argument in a partial specialization is permittedRichard Smith2016-12-281-7/+11
| | | | | | | | | | to make reference to template parameters. This is only a partial implementation; we retain the restriction that the argument must not be type-dependent, since it's unclear how that would work given the existence of other language rules requiring an exact type match in this context, even for type-dependent cases (a question has been raised on the core reflector). llvm-svn: 290647
* DR1495: A partial specialization is ill-formed if it is not (strictly) moreRichard Smith2016-12-271-2/+27
| | | | | | | | specialized than the primary template. (Put another way, if we imagine there were a partial specialization matching the primary template, we should never select it if some other partial specialization also matches.) llvm-svn: 290593
* Lit C++11 Compatibility Patch #7Charles Li2016-04-131-9/+38
| | | | | | | 13 tests have been updated for C++11 compatibility. Differential Revision: http://reviews.llvm.org/D19068 llvm-svn: 266239
* PR16519, PR18009: When checking a partial specialization for uses of its ownRichard Smith2014-02-091-0/+58
| | | | | | | | | | template parameters, don't look for parameters of outer templates. If a problem is found in a default template argument, point the diagnostic at the partial specialization (with a note pointing at the default argument) instead of pointing it at the default argument and leaving it unclear which partial specialization os problematic. llvm-svn: 201031
* Give a more appropriate diagnostic when a template specialization orRichard Smith2013-12-071-1/+1
| | | | | | | instantiation appears in a non-enclosing namespace (the previous diagnostic talked about the C++98 rule even in C++11 mode). llvm-svn: 196642
* Change the diagnostics which said 'accepted as an extension' to instead sayRichard Smith2011-12-291-1/+1
| | | | | | | 'is an extension'. The former is inappropriate and confusing when building with -Werror/-pedantic-errors. llvm-svn: 147357
* Diagnose class template (partial) specializations that occur in theDouglas Gregor2011-10-201-0/+10
| | | | | | | *wrong* class scope. This is one of the problems behind <rdar://problem/9676205>. llvm-svn: 142588
* When diagnosing C++ [temp.expl.spec]p3 in C++98/03 mode, downgrade theDouglas Gregor2010-09-121-1/+1
| | | | | | | | | | | error to a warning if we're in a case that would be allowed in C++0x. This "fixes" PR8084 by making Clang accept more code than GCC and (non-strict) EDG do. Also, add the missing test case for the C++0x semantics, which should have been in r113717. llvm-svn: 113718
* When pretty-printing tag types, only print the tag if we're in C (andJohn McCall2010-03-101-1/+1
| | | | | | | | | | therefore not creating ElaboratedTypes, which are still pretty-printed with the written tag). Most of these testcase changes were done by script, so don't feel too sorry for my fingers. llvm-svn: 98149
* Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.Daniel Dunbar2009-12-151-1/+1
| | | | | | | | | - This is designed to make it obvious that %clang_cc1 is a "test variable" which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it can be useful to redefine what gets run as 'clang -cc1' (for example, to set a default target). llvm-svn: 91446
* Require the object type of a member access expression ("." or "->") toDouglas Gregor2009-11-171-1/+1
| | | | | | be complete. llvm-svn: 89042
* Improve recovery in a wonky case where one tries to specialize aDouglas Gregor2009-11-121-0/+5
| | | | | | | | | | template template parameter. When building a template-id type, check whether the template-name itself is dependent (even if the template arguments are not!) and handle it as a template-id type. llvm-svn: 86913
* Only set the point of instantiation for an implicit or explicitDouglas Gregor2009-10-271-4/+8
| | | | | | | | | | instantiation once we have committed to performing the instantiation. As part of this, make our makeshift template-instantiation location information suck slightly less. Fixes PR5264. llvm-svn: 85209
* Diagnose the declaration of explicit specializations after an implicitDouglas Gregor2009-10-121-2/+4
| | | | | | | instantiation has already been required. To do so, keep track of the point of instantiation for anything that can be instantiated. llvm-svn: 83890
* Type checking for specializations of member functions of classDouglas Gregor2009-10-071-2/+3
| | | | | | | | templates. Previously, these weren't handled as specializations at all. The AST for representing these as specializations is still a work in progress. llvm-svn: 83498
* Refactor checking of the scope of explicit template specializationDouglas Gregor2009-10-071-2/+2
| | | | | | | | | declarations and explicit template instantiations, improving diagnostics and making the code usable for function template specializations (as well as class template specializations and partial specializations). llvm-svn: 83436
* Make sure to compare primary declaration contexts when determining whether a ↵Douglas Gregor2009-08-261-0/+19
| | | | | | declaration is in scope llvm-svn: 80126
* Initial infrastructure for class template partial specialization. HereDouglas Gregor2009-05-311-3/+0
| | | | | | | | | | | | | we have the basics of declaring and storing class template partial specializations, matching class template partial specializations at instantiation time via (limited) template argument deduction, and using the class template partial specialization's pattern for instantiation. This patch is enough to make a simple is_pointer type trait work, but not much else. llvm-svn: 72662
* Rename clang to clang-cc.Daniel Dunbar2009-03-241-1/+1
| | | | | | Tests and drivers updated, still need to shuffle dirs. llvm-svn: 67602
* Add pretty-printing for class template specializations, e.g.,Douglas Gregor2009-03-101-1/+1
| | | | | | | | | | | | | | | | 'struct A<double, int>' In the "template instantiation depth exceeded" message, print "-ftemplate-depth-N" rather than "-ftemplate-depth=N". An unnamed tag type that is declared with a typedef, e.g., typedef struct { int x, y; } Point; can be used as a template argument. Allow this, and check that we get sensible pretty-printing for such things. llvm-svn: 66560
* Implement the basics of implicit instantiation of class templates, inDouglas Gregor2009-03-031-3/+3
| | | | | | | | | | | | | | | | | | | | response to attempts to diagnose an "incomplete" type. This will force us to use DiagnoseIncompleteType more regularly (rather than looking at isIncompleteType), but that's also a good thing. Implicit instantiation is still very simplistic, and will create a new definition for the class template specialization (as it should) but it only actually instantiates the base classes and attaches those. Actually instantiating class members will follow. Also, instantiate the types of non-type template parameters before checking them, allowing, e.g., template<typename T, T Value> struct Constant; to work properly. llvm-svn: 65924
* Use RecordFirst/RecordLast range checks in DeclContextDouglas Gregor2009-02-261-3/+12
| | | | llvm-svn: 65489
* Improve location information on "reused" class template specializationDouglas Gregor2009-02-251-0/+7
| | | | | | | | decls. Test and document the semantic location of class template specialization definitions that occur within a scope enclosing the scope of the class template. llvm-svn: 65478
* Perform additional semantic checking of class templateDouglas Gregor2009-02-251-11/+33
| | | | | | | | | | | | specializations. In particular: - Make sure class template specializations have a "template<>" header, and complain if they don't. - Make sure class template specializations are declared/defined within a valid context. (e.g., you can't declare a specialization std::vector<MyType> in the global namespace). llvm-svn: 65476
* Include the appropriate header for mallocDouglas Gregor2009-02-251-1/+2
| | | | llvm-svn: 65471
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* Provide a proper source location when building an implicit dereference. ↵Douglas Gregor2009-02-191-0/+11
| | | | | | Fixes PR3600 llvm-svn: 64993
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-0/+31
specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
OpenPOWER on IntegriCloud