summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Reinstate r284008 reverted in r284081, with two fixes:Richard Smith2016-10-141-13/+34
| | | | | | | | | | | | | | | | | | | 1) Merge and demote variable definitions when we find a redefinition in MergeVarDecls, not only when we find one in AddInitializerToDecl (we only reach the second case if it's the addition of the initializer itself that converts an existing declaration into a definition). 2) When rebuilding a redeclaration chain for a variable, if we merge two definitions together, mark the definitions as merged so the retained definition is made visible whenever the demoted definition would have been. Original commit message (from r283882): [modules] PR28752: Do not instantiate variable declarations which are not visible. Original patch by Vassil Vassilev! Changes listed above are mine. llvm-svn: 284284
* Revert r284008. This is us to fail to instantiate static data members in someRichard Smith2016-10-121-34/+13
| | | | | | cases. I'm working on reducing a testcase. llvm-svn: 284081
* Reinstate r283887 and r283882.Vassil Vassilev2016-10-121-13/+34
| | | | | | | | | | | Original message: "[modules] PR28752: Do not instantiate variable declarations which are not visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith!" llvm-svn: 284008
* Revert r283887 and r283882, until the issue is understood and fixed.Vassil Vassilev2016-10-111-34/+13
| | | | llvm-svn: 283890
* [modules] PR28752: Do not instantiate variable declarations which are not ↵Vassil Vassilev2016-10-111-13/+34
| | | | | | | | | | visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith! llvm-svn: 283882
* [Sema] Use unique_ptr instead of raw pointers in the late-parsed templates map.Justin Lebar2016-10-101-2/+2
| | | | | | | | | | | | | | | Summary: This is possible now that MapVector supports move-only values. Depends on D25404. Reviewers: timshen Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25405 llvm-svn: 283766
* Factor out a diagnostic kind enum for use in two %select expressionsReid Kleckner2016-10-031-9/+3
| | | | | | NFC llvm-svn: 283131
* P0127R2: Support type deduction for types of non-type template parameters inRichard Smith2016-09-281-2/+31
| | | | | | | | C++1z. Patch by James Touton! Some bugfixes and rebasing by me. llvm-svn: 282651
* C++ Modules TS: Add parsing and some semantic analysis support forRichard Smith2016-09-081-3/+1
| | | | | | | export-declarations. These don't yet have an effect on name visibility; we still export everything by default. llvm-svn: 280999
* DR259: Demote the pedantic error for an explicit instantiation after anRichard Smith2016-08-311-7/+1
| | | | | | | | | explicit specialization to a warning for C++98 mode (this is a defect report resolution, so per our informal policy it should apply in C++98), and turn the warning on by default for C++11 and later. In all cases where it fires, the right thing to do is to remove the pointless explicit instantiation. llvm-svn: 280308
* PR12298 et al: don't recursively instantiate a template specialization fromRichard Smith2016-08-311-5/+8
| | | | | | | | | | | | | | | within the instantiation of that same specialization. This could previously happen for eagerly-instantiated function templates, variable templates, exception specifications, default arguments, and a handful of other cases. We still have an issue here for default template arguments that recursively make use of themselves and likewise for substitution into the type of a non-type template parameter, but in those cases we're producing a different entity each time, so they should instead be caught by the instantiation depth limit. However, currently we will typically run out of stack before we reach it. :( llvm-svn: 280190
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-231-13/+26
| | | | | | | | | | | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. This reinstates r279486, reverted in r279500, with a fix to DiagnoseUninstantiableTemplate to only mark uninstantiable explicit instantiation declarations as invalid if we actually diagnosed them. (When we trigger an explicit instantiation of a class member from an explicit instantiation declaration for the class, it's OK if there is no corresponding definition and we certainly don't want to mark the member invalid in that case.) This previously caused a build failure during bootstrap. llvm-svn: 279557
* Revert r279486 "Fix regression introduced by r279164"Chandler Carruth2016-08-231-23/+10
| | | | | | | Build bots seem unhappy and as Richard was leaving he asked me to revert this for him. Doing so. llvm-svn: 279500
* Fix regression introduced by r279164: only pass definitions as the PatternDefRichard Smith2016-08-221-10/+23
| | | | | | | | | | | | | | | | to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly determine whether a function definition is visible, and mark both the function and the template as visible when merging function template definitions to provide hasVisibleDefinition with the relevant information. The change to always pass the right declaration as the PatternDef to DiagnoseUninstantiableTemplate also caused those checks to happen before other diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the same situations, so I sunk the relevant diagnostics into DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes in reviews.llvm.org/D23492 by Vassil Vassilev. llvm-svn: 279486
* PR28794: Don't try to instantiate function templates which are not visible.Vassil Vassilev2016-08-181-0/+64
| | | | | | Reviewed by Richard Smith. llvm-svn: 279164
* P0217R3: Perform semantic checks and initialization for the bindings in aRichard Smith2016-08-111-5/+2
| | | | | | | decomposition declaration for arrays, aggregate-like structs, tuple-like types, and (as an extension) for complex and vector types. llvm-svn: 278435
* Move helpers into anonymous namespaces. NFC.Benjamin Kramer2016-08-061-0/+2
| | | | llvm-svn: 277918
* Reapply r276069 with workaround for MSVC 2013Hubert Tong2016-07-301-3/+2
| | | | llvm-svn: 277286
* Revert r276069: MSVC bots not happyHubert Tong2016-07-201-2/+3
| | | | llvm-svn: 276074
* Concepts: Create space for requires-clause in TemplateParameterList; NFCHubert Tong2016-07-201-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Space for storing the //constraint-expression// of the //requires-clause// associated with a `TemplateParameterList` is arranged by taking a bit out of the `NumParams` field for the purpose of determining whether there is a //requires-clause// or not, and by adding to the trailing objects tied to the `TemplateParameterList`. An accessor is provided. An appropriate argument is supplied to `TemplateParameterList::Create` at the various call sites. Serialization changes will addressed as the Concepts implementation becomes more solid. Drive-by fix: This change also replaces the custom `FixedSizeTemplateParameterListStorage` implementation with one that follows the interface provided by `llvm::TrailingObjects`. Reviewers: aaron.ballman, faisalv, rsmith Subscribers: cfe-commits, nwilson Differential Revision: https://reviews.llvm.org/D19322 llvm-svn: 276069
* [AST] Keep track of the left brace source location of a tag decl.Argyrios Kyrtzidis2016-07-151-1/+1
| | | | | | This is useful for source modification tools. There will be a follow-up commit using it. llvm-svn: 275590
* [Sema] Don't artificially forbid BuiltinTemplateDecls in CheckTemplateArgumentDavid Majnemer2016-07-111-7/+6
| | | | | | | | After thinking about it, we don't really need to forbid BuiltinTemplateDecls explicitly. The restriction doesn't really buy us anything. llvm-svn: 275078
* [Sema] Disallow __make_integer_seq from showing up in __make_integer_seqDavid Majnemer2016-07-111-4/+6
| | | | | | | | | We hit over stringent asserts when trying to diagnose. Loosen them as appropriate. This fixes PR28494. llvm-svn: 275047
OpenPOWER on IntegriCloud