summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [AST] Use ArrayRef in more interfacesDavid Majnemer2016-07-071-9/+5
| | | | | | | | | ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274732
* [AST] Use ArrayRef in more interfacesDavid Majnemer2016-07-031-21/+13
| | | | | | | | ArrayRef is a little better than passing around a pointer/length pair. No functional change is intended. llvm-svn: 274475
* [Feature] Add a builtin for indexing into parameter packs. Patch by Louis ↵Eric Fiselier2016-07-011-1/+25
| | | | | | | | | | | | | Dionne. This patch adds a __nth_element builtin that allows fetching the n-th type of a parameter pack with very little compile-time overhead. The patch was inspired by r252036 and r252115 by David Majnemer, which add a similar __make_integer_seq builtin for efficiently creating a std::integer_sequence. Reviewed as D15421. http://reviews.llvm.org/D15421 llvm-svn: 274316
* Fix PR28100 - Allow redeclarations of deleted explicit specializations.Faisal Vali2016-06-141-6/+14
| | | | | | | | | | | | See https://llvm.org/bugs/show_bug.cgi?id=28100. In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status. All regression tests pass. Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention. llvm-svn: 272631
* Fix recognition of shadowed template parameterSerge Pavlov2016-06-101-6/+8
| | | | | | | | | | | | | | | | | | | | | | | Crash reported in PR28023 is caused by the fact that non-type template parameters are found by tag name lookup. In the code provided in that PR: template<int V> struct A { struct B { template <int> friend struct V; }; }; the template parameter V is found when lookup for redeclarations of 'struct V' is made. Latter on the error about shadowing of 'V' is emitted but the semantic context of 'struct V' is already determined wrong: 'struct A' instead of translation unit. The fix moves the check for shadowing toward the beginning of the method and thus prevents from wrong context calculations. This change fixes PR28023. llvm-svn: 272366
* Re-commit r270748 "clang-cl: Treat dllimport explicit template instantiation ↵Hans Wennborg2016-05-261-2/+31
| | | | | | | | | | definitions as declarations (PR27810, PR27811)" Also make explicit instantiation decls not apply to nested classes when targeting MSVC. That dll attributes are not inherited by inner classes might be the explanation for MSVC's behaviour here. llvm-svn: 270897
* Revert r270748 "clang-cl: Treat dllimport explicit template instantiation ↵Hans Wennborg2016-05-251-31/+2
| | | | | | | | | definitions as declarations (PR27810, PR27811)" It seems to have broken the sanitizer-windows bot. Reverting while investigating. llvm-svn: 270754
* clang-cl: Treat dllimport explicit template instantiation definitions as ↵Hans Wennborg2016-05-251-2/+31
| | | | | | | | | | | declarations (PR27810, PR27811) This matches what MSVC does, and should make compiles faster by avoiding to unnecessarily emit a lot of code. Differential Revision: http://reviews.llvm.org/D20608 llvm-svn: 270748
* Properly track the found declaration (possibly a using-declaration) whenRichard Smith2016-05-241-2/+7
| | | | | | handling an explicit member specialization. llvm-svn: 270514
* Preserve the FoundDecl when performing overload resolution for constructors.Richard Smith2016-05-111-7/+9
| | | | | | | | | This is in preparation for C++ P0136R1, which switches the model for inheriting constructors over from synthesizing a constructor to finding base class constructors (via using shadow decls) when looking for derived class constructors. llvm-svn: 269231
* [modules] Enforce the rules that an explicit or partial specialization must beRichard Smith2016-05-051-4/+154
| | | | | | | | declared before it is used. Because we don't use normal name lookup to find these, the normal code to filter out non-visible names from name lookup results does not apply. llvm-svn: 268585
* [Concepts] Pass requires-clause to ActOnTemplateParameterList; NFCHubert Tong2016-04-291-3/+6
| | | | | | | | | | | | | | Summary: Prepare to store requires-clause expression for access via TemplateParameterList. Reviewers: aaron.ballman, faisalv, rsmith Subscribers: cfe-commits, nwilson Differential Revision: http://reviews.llvm.org/D19220 llvm-svn: 268081
* Implement CWG 941 - explicit specializations of deleted function templatesFaisal Vali2016-04-171-0/+14
| | | | | | | | | | | | | | | | | | | template<class T> void f(T) = delete; template<> void f(int); // OK. f(3); // OK Implementation strategy: When an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization. The problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted). The present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false. I suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution. But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path. Hopefully it'll prove to not be a bad choice. llvm-svn: 266561
* [Concepts] Implement subsection [dcl.spec.concept]p7 of the Concepts TSNathan Wilson2016-04-091-0/+28
| | | | | | | | | | | | Summary: A program shall not declare an explicit instantiation (14.8.2), an explicit specialization (14.8.3), or a partial specialization of a concept definition. Reviewers: rsmith, hubert.reinterpretcast, faisalv, aaron.ballman Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18221 llvm-svn: 265868
* Fix a crash on invalid with template handlingRichard Trieu2016-04-051-6/+12
| | | | | | | | This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a crash on invalid. Change the handling of invalid decls to have a catch-all case to prevent unexpecting decls from triggering an assertion. llvm-svn: 265467
* [NFC] Tweak diagnostic for template template arguments, to include template ↵Faisal Vali2016-03-261-2/+2
| | | | | | | | aliases. The prior diagnostic (err_template_arg_not_class_template) would state that the template argument to a template template parameter can only be a class template, when it can also be a template alias. The newly renamed diagnostic (err_template_arg_not_valid_template) mentions template aliases. llvm-svn: 264522
* Allow sizeof(UnrelatedClass::field) in C++11 class template methodsReid Kleckner2016-03-111-3/+16
| | | | | | | | | | | | | | | | | This feature works outside of templates by forming a DeclRefExpr to a FieldDecl instead of a MemberExpr, which requires a base object in addition to the FieldDecl. Previously, while building up the template AST before instantiation, we formed a CXXDependentScopeMemberExpr, which always instantiates to a MemberExpr. Now, in unevaluated contexts we form a DependentScopeDeclRefExpr, which is a more flexible node that can instantiate to either a MemberExpr or a DeclRefExpr depending on lookup results. Fixes PR26893. llvm-svn: 263279
* [dllexport] Sort out emission order of delayed exported classesReid Kleckner2016-02-261-0/+6
| | | | | | | | | | | | | | | | Relands r260194 with a fix. If we have a template that transitions from an extern template to an explicitly instantiated dllexport template, we would add that class to the delayed exported class list without flushing it. For explicit instantiations, we can just flush the list of delayed classes immediately. We don't have to worry about the bug fixed in r260194 in this case because explicit instantiations can only occur at file and namespace scope. Fixes PR26490. llvm-svn: 262056
* Removed unused local variableSerge Pavlov2016-02-191-3/+0
| | | | llvm-svn: 261323
* Fix remaining Clang-tidy readability-redundant-control-flow warnings; other ↵Eugene Zelenko2016-02-121-9/+8
| | | | | | | | minor fixes. Differential revision: http://reviews.llvm.org/D17218 llvm-svn: 260757
* [Concepts] Implement a portion of Concepts TS[dcl.spec.concept]p1 byNathan Wilson2016-02-081-0/+9
| | | | | | | | | | | | | | diagnosing when 'concept' is specified on a function or template specialization. Since a concept can only be applied to a function or variable template, the concept bit is stored in TemplateDecl as a PointerIntPair. Reviewers: rsmith, faisalv, aaron.ballman, hubert.reinterpretcast Differential Revision: http://reviews.llvm.org/D13357 llvm-svn: 260074
* Fix PR26134: When substituting into default template arguments, keep ↵Faisal Vali2016-01-191-1/+0
| | | | | | | | | | | | | | | CurContext unchanged. Or, do not set Sema's CurContext to the template declaration's when substituting into default template arguments of said template declaration. If we do push the template declaration context on to Sema, and the template declaration is at namespace scope, Sema can get confused and try and do odr analysis when substituting into default template arguments, even though the substitution could be occurring within a dependent context. I'm not sure why this was being done, perhaps there was concern that if a default template argument referred to a previous template parameter, it might not be found during substitution - but all regression tests pass, and I can't craft a test that would cause it to fails (if some one does, please inform me, and i'll craft a different fix for the PR). This patch removes a single line of code, but unfortunately adds more than it removes, because of the tests. Some day I still hope to commit a patch that removes far more lines than it adds, while leaving clang better for it ;) Sorry that r253590 ("Change the expression evaluation context from Unevaluated to ConstantEvaluated while substituting into non-type template argument defaults") caused the PR! llvm-svn: 258110
* OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedefDavid Blaikie2016-01-151-1/+1
| | | | llvm-svn: 257958
OpenPOWER on IntegriCloud