summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Factor out function to determine whether we're performing a templateRichard Smith2017-02-211-1/+1
| | | | | | | | | instantiation. In preparation for converting the template stack to a more general context stack (so we can include context notes for other kinds of context). llvm-svn: 295686
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-15/+14
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* Properly set up the DeclContext for parameters of implicit deduction guides;Richard Smith2017-02-161-2/+7
| | | | | | this is needed for deferred instantiation of default arguments. llvm-svn: 295379
* [c++1z] Diagnose non-deducible template parameters in deduction guide ↵Richard Smith2017-02-161-13/+41
| | | | | | templates, per [temp.param]p11. llvm-svn: 295264
* Canonicalize implicit deduction guide parameter types when forming a deductionRichard Smith2017-02-141-9/+19
| | | | | | | | | | | | guide from a constructor. The purpose of this change is to avoid triggering instantiation of the class when substituting back into the deduction guide if it uses a typedef member. We will still instantiate the class if the constructor (explicitly or implicitly, directly or indirectly) uses the current instantiation in a way that we can't canonicalize out, but that seems unavoidable. llvm-svn: 295016
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-0/+344
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* [c++1z] Enforce restriction that deduction guide is declared in the same ↵Richard Smith2017-02-101-0/+31
| | | | | | scope as its template. llvm-svn: 294778
* [Concepts] Class template associated constraintsHubert Tong2017-02-101-1/+52
| | | | | | | | | | | | | | | | Summary: This adds associated constraints as a property of class templates. An error is produced if redeclarations are not similarly constrained. Reviewers: rsmith, faisalv, aaron.ballman Reviewed By: rsmith Subscribers: cfe-commits, nwilson Differential Revision: https://reviews.llvm.org/D25674 llvm-svn: 294697
* Disallow explicit instantiation and explicit specialization for deduction ↵Richard Smith2017-02-091-0/+8
| | | | | | guides. llvm-svn: 294641
* Rename IsExplicitSpecialization -> IsMemberSpecialization when we're talkingRichard Smith2017-02-091-13/+11
| | | | | | about member specializations to avoid ambiguous and confusing terminology. llvm-svn: 294622
* Repoint 'missing typename' diagnostic to the location where 'typename' ↵Richard Smith2017-02-011-1/+1
| | | | | | should be added. llvm-svn: 293817
* Fix hole in our enforcement of rule requiring 'typename' prior to a dependentRichard Smith2017-02-011-15/+36
| | | | | | | | | | | name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we would fail to notice that the 'typename' keyword is missing when resolving it to a type. It turns out that GCC has a similar bug. If this shows up in much real code, we can easily downgrade this to an ExtWarn. llvm-svn: 293815
* Towards P0091R3: parsing support for class template argument deduction in ↵Richard Smith2017-01-301-2/+12
| | | | | | | | | typename-specifiers. This reinstates r293455, reverted in r293455, with a fix for cv-qualifier handling on dependent typename-specifiers. llvm-svn: 293544
* Revert r293455, which breaks v8 with a spurious error. Testcase added.Sam McCall2017-01-301-12/+2
| | | | | | | | | | | | Summary: Revert r293455, which breaks v8 with a spurious error. Testcase added. Reviewers: klimek Subscribers: cfe-commits, rsmith Differential Revision: https://reviews.llvm.org/D29271 llvm-svn: 293473
* Towards P0091R3: parsing support for class template argument deduction in ↵Richard Smith2017-01-301-2/+12
| | | | | | typename-specifiers. llvm-svn: 293455
* When converting a template argument representing &array to an expression for aRichard Smith2017-01-281-2/+3
| | | | | | | 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-261-0/+8
| | | | | | | | | | | | | | | 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
* Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-201-1/+20
| | | | | | | Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-10/+61
| | | | | | | | | | | | | | | | | | | | | | 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
* PR9551: Implement DR1004 (http://wg21.link/cwg1004).Richard Smith2017-01-181-6/+51
| | | | | | | | This rule permits the injected-class-name of a class template to be used as both a template type argument and a template template argument, with no extra syntax required to disambiguate. llvm-svn: 292426
* Partial revert of r290511.Richard Smith2017-01-171-12/+16
| | | | | | | | | | | | | | | | 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-7/+3
| | | | | | | | | diagnostics. We were previouly assuming that every type template was a class template, which is not true any more. llvm-svn: 291988
* [Sema] Restrict explicit instantation definition dllexportShoaib Meenai2017-01-131-2/+4
| | | | | | | | | | | | | | | | In the case where the template class itself is already `dllexport`, the implicit instantiation will have already emitted all members. When we check the explicit instantiation definition, the `Specialization` will have inherited the `dllexport` attribute, so we'll attempt to emit all members for a second time, which causes an assertion failure. Restrict the exporting to when the `dllexport` attribute is newly introduced by the explicit instantiation definition. Fixes PR31608. Differential Revision: https://reviews.llvm.org/D28590 llvm-svn: 291877
* PR31469: Don't add friend template class decls to redecl chain in dependent ↵Vassil Vassilev2017-01-121-2/+14
| | | | | | | | | | | | | | | | | contexts. Fixes a crash in modules where the template class decl becomes the most recent decl in the redeclaration chain and forcing the template instantiator try to instantiate the friend declaration, rather than the template definition. In practice, A::list<int> produces a TemplateSpecializationType A::__1::list<int, allocator<type-parameter-0-0> >' failing to replace to subsitute the default argument to allocator<int>. Kudos Richard Smith (D28399). llvm-svn: 291753
* Remove fixme, use ASTContext::getCanonicalTemplateSpecializationType.Vassil Vassilev2017-01-101-10/+2
| | | | | | Reviewed by Richard Smith (D28306). llvm-svn: 291552
* Check that template template arguments match template template parametersRichard Smith2017-01-091-19/+19
| | | | | | | | | | | | | | | 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
* Revisit PR10177: don't instantiate a variable if it's only referenced in aRichard Smith2017-01-061-0/+5
| | | | | | | | | | | | | | dependent context and can't be used in a constant expression. Per C++ [temp.inst]p2, "the instantiation of a static data member does not occur unless the static data member is used in a way that requires the definition to exist". This doesn't /quite/ match that, as we still instantiate static data members that are usable in constant expressions even if the use doesn't require a definition. A followup patch will fix that for both variables and functions. llvm-svn: 291295
* Remove isIgnored()-test that is more expensive than the analysis behind itDaniel Jasper2017-01-021-12/+2
| | | | | | | | | | In many translation units I have tried, the calls to isIgnored() removed in this patch are more expensive than doing the analysis that is behind it. The speed-up in translation units I have tried is between 10 and 20%. Review: https://reviews.llvm.org/D28208 llvm-svn: 290842
* [c++17] Implement P0522R0 as written. This allows a template template argumentRichard Smith2016-12-311-1/+27
| | | | | | | | | | | | | | | | | | | to be specified for a template template parameter whenever the parameter is at least as specialized as the argument (when there's an obvious and correct mapping from uses of the parameter to uses of the argument). For example, a template with more parameters can be passed to a template template parameter with fewer, if those trailing parameters have default arguments. This is disabled by default, despite being a DR resolution, as it's fairly broken in its current state: there are no partial ordering rules to cope with template template parameters that have different parameter lists, meaning that code that attempts to decompose template-ids based on arity can hit unavoidable ambiguity issues. The diagnostics produced on a non-matching argument are also pretty bad right now, but I aim to improve them in a subsequent commit. llvm-svn: 290792
* Wdocumentation fixSimon Pilgrim2016-12-301-133/+133
| | | | llvm-svn: 290773
* Mark 'auto' as dependent when instantiating the type of a non-type templateRichard Smith2016-12-281-8/+23
| | | | | | | parameter. Fixes failed deduction for 'auto' non-type template parameters nested within templates. llvm-svn: 290660
* DR1315: a non-type template argument in a partial specialization is permittedRichard Smith2016-12-281-107/+127
| | | | | | | | | | 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
* Add warning flag for "partial specialization is not more specialized than ↵Richard Smith2016-12-271-2/+2
| | | | | | primary template" error (since Eigen hits it), and while I'm here also add a warning flag for "partial specialization is not usable because one or more of its parameters cannot be deduced" warning. llvm-svn: 290625
* DR1495: A partial specialization is ill-formed if it is not (strictly) moreRichard Smith2016-12-271-2/+45
| | | | | | | | 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
* Work around a standard defect: template argument deduction for non-typeRichard Smith2016-12-271-1/+7
| | | | | | | | | template parameters of reference type basically doesn't work, because we're always deducing from an argument expression of non-reference type, so the type of the deduced expression never matches. Instead, compare the type of an expression naming the parameter to the type of the argument. llvm-svn: 290586
* Check and build conversion sequences for non-type template arguments inRichard Smith2016-12-271-10/+8
| | | | | | | dependent contexts when processing the template in C++11 and C++14, just like we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier. llvm-svn: 290567
* Update comment to match dr1770.Richard Smith2016-12-261-8/+7
| | | | llvm-svn: 290552
* Fix some subtle wrong partial ordering bugs particularly with C++1z auto-typedRichard Smith2016-12-251-9/+15
| | | | | | | | | | | | | | | | | | non-type template parameters. During partial ordering, when checking the substituted deduced template arguments match the original, check the types of non-type template arguments match even if they're dependent. The only way we get dependent types here is if they really represent types of the other template (which are supposed to be modeled as being substituted for unique, non-dependent types). In order to make this work for auto-typed non-type template arguments, we need to be able to perform auto deduction even when the initializer and (potentially) the auto type are dependent, support for which is the bulk of this patch. (Note that this requires the ability to deduce only a single level of a multi-level dependent type.) llvm-svn: 290511
* When producing a name of a partial specialization in a diagnostic, use theRichard Smith2016-12-241-2/+1
| | | | | | | template arguments as written rather than the canonical template arguments, so we print more user-friendly names for template parameters. llvm-svn: 290483
* Perform type-checking for a converted constant expression in a templateRichard Smith2016-12-211-7/+7
| | | | | | | | | | | argument even if the expression is value-dependent (we need to suppress the final portion of the narrowing check, but the rest of the checking can still be done eagerly). This affects template template argument validity and partial ordering under p0522r0. llvm-svn: 290276
* [Sema] Fix handling of enumerators used as default arguments of lambdaAkira Hatanaka2016-12-161-1/+6
| | | | | | | | | | | | | | | | | expressions in a function or class template. This patch makes the following changes: - Create a DependentScopeDeclRefExpr for the default argument instead of a CXXDependentScopeMemberExpr. - Pass CombineWithOuterScope=true so that the outer scope in which the enum is declared is searched for the instantiation of the enum. This is the first part of https://reviews.llvm.org/D23096. Fixes PR28795 rdar://problem/27535319 llvm-svn: 289914
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-091-3/+4
| | | | | | | | | | | | | | | | | | | | Other compilers accept invalid code here that we reject, and we need a better error message to try to convince users that the code is really incorrect. Consider: class Foo { typedef MyIterHelper<Foo> iterator; friend class iterator; }; Previously our wording was "elaborated type refers to a typedef". "elaborated type" isn't widely known terminology, so the new diagnostic says "typedef 'iterator' cannot be referenced with class specifier". Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D25216 llvm-svn: 289259
* [CUDA] Ignore implicit target attributes during function template instantiation.Artem Belevich2016-12-081-24/+29
| | | | | | | | | | | | | | | | | | | | | | | Some functions and templates are treated as __host__ __device__ even when they don't have explicitly specified target attributes. What's worse, this treatment may change depending on command line options (-fno-cuda-host-device-constexpr) or #pragma clang force_cuda_host_device. Combined with strict checking for matching function target that comes with D25809(r288962), it makes it hard to write code which would explicitly instantiate or specialize some functions regardless of pragmas or command line options in effect. This patch changes the way we match target attributes of base template vs attributes used in explicit instantiation or specialization so that only explicitly specified attributes are considered. This makes base template selection behave consistently regardless of pragma of command line options that may affect CUDA target. Differential Revision: https://reviews.llvm.org/D25845 llvm-svn: 289091
* [CUDA] Improve target attribute checking for function templates.Artem Belevich2016-12-071-1/+34
| | | | | | | | | | | | * __host__ __device__ functions are no longer considered to be redeclarations of __host__ or __device__ functions. This prevents unintentional merging of target attributes across them. * Function target attributes are not considered (and must match) during explicit instantiation and specialization of function templates. Differential Revision: https://reviews.llvm.org/D25809 llvm-svn: 288962
* [Sema] Respect DLL attributes more faithfullyShoaib Meenai2016-12-051-15/+48
| | | | | | | | | | | On MSVC, if an implicit instantiation already exists and an explicit instantiation definition with a DLL attribute is created, the DLL attribute still takes effect. Make clang match this behavior for exporting. Differential Revision: https://reviews.llvm.org/D26657 llvm-svn: 288682
* Sema: delay the DLL exported member referencingSaleem Abdulrasool2016-12-031-1/+2
| | | | | | | | | | | | | | An explicit template specialization can cause the implicit template specialization of a type which inherits the attributes. In such a case, we would end up with a delayed template specialization for a dll exported type which we would fail to reference. This would trigger an assertion. We now propagate the dll storage attributes through the inheritance chain. Only after having done so do we reference the delayed template specializations. This allows any implicit specializations which inherit dll storage to also be referenced. llvm-svn: 288570
* PR31081: ignore exception specifications when deducing function templateRichard Smith2016-12-011-1/+2
| | | | | | | arguments from a declaration; despite what the standard says, this form of deduction should not be considering exception specifications. llvm-svn: 288301
* Rangify for loop, NFC.Yaron Keren2016-11-161-6/+4
| | | | llvm-svn: 287102
* [Sema] Use MS ABI behavior for dllexport in ItaniumShoaib Meenai2016-11-091-1/+2
| | | | | | | | | | Similar to r284288, make the Itanium ABI follow MS ABI dllexport semantics in the case of an explicit instantiation declaration followed by a dllexport explicit instantiation definition. Differential Revision: https://reviews.llvm.org/D26471 llvm-svn: 286419
* Add a note that points to the linkage specifier for the C++ linkage errorsAlex Lorenz2016-11-021-3/+7
| | | | | | | | | | | | This commit improves the "must have C++ linkage" error diagnostics that are emitted for C++ declarations like templates and literal operators by adding an additional note that points to the appropriate extern "C" linkage specifier. rdar://19021120 Differential Revision: https://reviews.llvm.org/D26189 llvm-svn: 285823
OpenPOWER on IntegriCloud