summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-5/+8
| | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. llvm-svn: 315251
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-1/+0
| | | | llvm-svn: 315196
* Dependent Address Space SupportAndrew Gozillon2017-10-021-0/+5
| | | | | | | | | | | | | | This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
* Diagnostic specific failed condition in a static_assert.Douglas Gregor2017-09-141-14/+23
| | | | | | | | When a static_assert fails, dig out a specific condition to diagnose, using the same logic that we use to find the enable_if condition to diagnose. llvm-svn: 313315
* [NFC] Remove a cstyle cast and replace some uses of Decl with NamedDecl ↵Faisal Vali2017-08-251-2/+2
| | | | | | during the processing of TemplateParameterLists. llvm-svn: 311788
* [MS] Don't statically initialize dllimport member function pointersReid Kleckner2017-07-071-40/+40
| | | | | | | | | | | | | | | | | | | | Summary: r306137 made dllimport pointers to member functions non-constant. This is correct because a load must be executed to resolve any dllimported data. However, r306137 did not account for the use of dllimport member function pointers used as template arguments. This change re-lands r306137 with a template instantiation fix. This fixes PR33570. Reviewers: rnk, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34714 llvm-svn: 307446
* Fix test case in pre-C++11 mode; address Aaron Ballman's code review.Douglas Gregor2017-07-051-2/+2
| | | | llvm-svn: 307202
* Cope with Range-v3's CONCEPT_REQUIRES idiomDouglas Gregor2017-07-051-0/+34
| | | | llvm-svn: 307197
* Customize the SFINAE diagnostics for enable_if to provide the failed condition.Douglas Gregor2017-07-051-7/+131
| | | | | | | | | | | | | | | | | | | | 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
* [Sema] Fix a crash-on-invalid when a template parameter list has a classAkira Hatanaka2017-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | definition or non-reference class type. The crash occurs when there is a template parameter list in a class that is missing the closing angle bracket followed by a definition of a struct. For example: class C0 { public: template<typename T, typename T1 = T // missing closing angle bracket struct S0 {}; C0() : m(new S0<int>) {} S0<int> *m; }; This happens because the parsed struct is added to the scope of the enclosing class without having its access specifier set, which results in an assertion failure in SemaAccess.cpp later. This commit fixes the crash by adding the parsed struct to the enclosing file scope and marking structs as invalid if they are defined in template parameter lists. rdar://problem/31783961 rdar://problem/19570630 Differential Revision: https://reviews.llvm.org/D33606 llvm-svn: 306317
* Added llvm_unreachable to make sure the switch is always exhaustive.Galina Kistanova2017-06-081-0/+1
| | | | llvm-svn: 304997
* When determining the target function of an explicit instantiation, makeJohn McCall2017-06-071-19/+25
| | | | | | | | | | sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch by Don Hinton! llvm-svn: 304951
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-071-0/+3
| | | | llvm-svn: 304870
* [modules] Switch from inferring owning modules based on source location toRichard Smith2017-05-181-1/+3
| | | | | | | | | | | | | | | inferring based on the current module at the point of creation. This should result in no functional change except when building a preprocessed module (or more generally when using #pragma clang module begin/end to switch module in the middle of a file), in which case it allows us to correctly track the owning module for declarations. We can't map from FileID to module in the preprocessed module case, since all modules would have the same FileID. There are still a couple of remaining places that try to infer a module from a source location; I'll clean those up in follow-up changes. llvm-svn: 303322
* Remove unnecessary mapping from SourceLocation to Module.Richard Smith2017-05-111-3/+3
| | | | | | | | When we parse a redefinition of an entity for which we have a hidden existing declaration, make it visible in the current module instead of mapping the current source location to its containing module. llvm-svn: 302842
* Improve diagnosis of unknown template name.Richard Smith2017-05-101-2/+2
| | | | | | | | | 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/+79
| | | | | | | | | | | | | | | | | | | 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
* Don't mark a member as a member specialization until we know we're keeping ↵Richard Smith2017-05-091-48/+63
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* PR32673: Don't wrap parameter packs in SubstTemplateTypeParmPackType nodes ↵Richard Smith2017-04-201-5/+16
| | | | | | | | | when forming implicit deduction guides. Doing so thwarts template type deduction. Instead, substitute the pack directly by picking "slice 0" of the resulting expansion. llvm-svn: 300805
* PR32185: Revert r291512 and add a testcase for PR32185.Richard Smith2017-04-131-19/+19
| | | | | | | | | | | | | | | 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
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-4/+4
| | | | | | | | - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
* Fix typo, defind -> defined.Eric Christopher2017-03-311-1/+1
| | | | llvm-svn: 299148
* Correct class-template deprecation behavior-REDUXErich Keane2017-03-231-0/+7
| | | | | | | | | | | | | | | | | | Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
* Revert "Correct class-template deprecation behavior"Martin Bohme2017-03-221-7/+0
| | | | | | | This reverts commit r298410 (which produces incorrect warnings, see comments on https://reviews.llvm.org/rL298410). llvm-svn: 298504
* Correct class-template deprecation behaviorErich Keane2017-03-211-0/+7
| | | | | | | | | | | | | Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Differential Revision: https://reviews.llvm.org/D27486 llvm-svn: 298410
* Improve support for 'decltype(auto)' in template template parameter matching.Richard Smith2017-02-221-0/+13
| | | | | | | | | | | | | | | 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
* PR32010: Fix template argument depth mixup when forming implicit constructorRichard Smith2017-02-211-2/+6
| | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud