summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Suppress undefined-template warnings when the pattern is declared in a ↵Nick Lewycky2018-01-021-2/+4
| | | | | | | | system header. The way to fix an undefined-template warning is to add lines to the header file that defines the template pattern. We should suppress the warnings when the template pattern is in a system header because we don't expect users to edit those. llvm-svn: 321665
* [Frontend] Correctly handle instantiating ctors with skipped bodiesIlya Biryukov2017-12-281-13/+13
| | | | | | | | | | | | | | | | Summary: Previsouly clang tried instantiating member initializers even if ctor body was skipped, this caused spurious errors (see the test). Reviewers: sepavloff, klimek Reviewed By: sepavloff Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D41492 llvm-svn: 321520
* When instantiating a deduction guide, transform its name.Richard Smith2017-12-211-3/+7
| | | | | | Otherwise it will serve as a deduction guide for the wrong class template. llvm-svn: 321297
* [Frontend] Handle skipped bodies in template instantiationsIlya Biryukov2017-12-201-9/+14
| | | | | | | | | | | | | | | | | | Summary: - Fixed an assert in Sema::InstantiateFunctionDefinition and added support for instantiating a function template with skipped body. - Properly call setHasSkippedBody for FunctionTemplateDecl passed to Sema::ActOnSkippedFunctionBody. Reviewers: sepavloff, bkramer Reviewed By: sepavloff Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D41237 llvm-svn: 321174
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-1/+3
| | | | llvm-svn: 321115
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-18/+12
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* PR35456: Track definedness of variable template specializations separately fromRichard Smith2017-12-021-0/+9
| | | | | | | | | | whether they have an initializer. We cannot distinguish between a declaration of a variable template specialization and a definition of one that lacks an initializer without this, and would previously mistake the latter for the former. llvm-svn: 319605
* Never try to instantiate a deduction guide's "definition". Fixes bogus ↵Richard Smith2017-10-281-1/+2
| | | | | | warning when there inevitably isn't one. llvm-svn: 316820
* [C++17] Fix PR34970 - tweak overload resolution for class template ↵Faisal Vali2017-10-221-4/+6
| | | | | | | | | | | | | | | | | | | deduction-guides in line with WG21's p0620r0. In order to identify the copy deduction candidate, I considered two approaches: - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution. - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union. Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added. References: See https://bugs.llvm.org/show_bug.cgi?id=34970 See http://wg21.link/p0620r0 llvm-svn: 316292
* Don't suppress instantiation of definitions for variables subject to explicitRichard Smith2017-10-181-2/+4
| | | | | | | | | instantiation declarations if they are usable from constant expressions. We are permitted to instantiate in these cases, and required to do so in order to have an initializer available for use within constant evaluation. llvm-svn: 316136
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-7/+10
| | | | | | | | | | | | | | | | | 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. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-101-10/+7
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-7/+10
| | | | | | | | | | 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
* PR33839: Fix -Wunused handling for structured binding declarations.Richard Smith2017-10-021-0/+1
| | | | | | | We warn about a structured binding declaration being unused only if none of its bindings are used. llvm-svn: 314733
* Give external linkage and mangling to lambdas inside inline variables and ↵Richard Smith2017-09-221-8/+2
| | | | | | | | | | | variable templates. This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33 This reinstates r313827, reverted in r313856, with a fix for the 'out-of-bounds enumeration value' ubsan error in that change. llvm-svn: 313955
* Revert "Give external linkage and mangling to lambdas inside inline ↵Vitaly Buka2017-09-211-2/+8
| | | | | | | | | | variables and variable templates." To fix: runtime error: load of value 15, which is not a valid value for type 'clang::LVComputationKind' This reverts commit r313827. llvm-svn: 313856
* Give external linkage and mangling to lambdas inside inline variables and ↵Richard Smith2017-09-201-8/+2
| | | | | | | | variable templates. This implements the proposed approach in https://github.com/itanium-cxx-abi/cxx-abi/issues/33 llvm-svn: 313827
* [OPENMP] Fix for PR34445: Reduction initializer segfaults at runtime inAlexey Bataev2017-09-061-10/+22
| | | | | | | | | | move constructor. Previously user-defined reduction initializer was considered as an assignment expression, not as initializer. Fixed this by treating the initializer expression as an initializer. llvm-svn: 312638
* PR34163: Don't cache an incorrect key function for a class if queried betweenRichard Smith2017-08-121-0/+2
| | | | | | | | | | | the class becoming complete and its inline methods being parsed. This replaces the hack of using the "late parsed template" flag to track member functions with bodies we've not parsed yet; instead we now use the "will have body" flag, which carries the desired implication that the function declaration *is* a definition, and that we've just not parsed its body yet. llvm-svn: 310776
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-2/+2
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* PR33002: When we instantiate the definition of a static data member, we mightRichard Smith2017-06-221-4/+0
| | | | | | | have attached an initializer to the in-class declaration. If so, include the initializer in the update record for the instantiation. llvm-svn: 306065
* Function with unparsed body is a definitionSerge Pavlov2017-06-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 This is a recommit of 305379, reverted in 305381, with small changes. llvm-svn: 305903
* Prevent devirtualization of calls to un-instantiated functions.Sunil Srivastava2017-06-201-0/+4
| | | | | | | | PR 27895 Differential Revision: https://reviews.llvm.org/D22057 llvm-svn: 305862
* Reverted 305379 (Function with unparsed body is a definition)Serge Pavlov2017-06-141-6/+1
| | | | | | It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots. llvm-svn: 305381
* Function with unparsed body is a definitionSerge Pavlov2017-06-141-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While a function body is being parsed, the function declaration is not considered as a definition because it does not have a body yet. In some cases it leads to incorrect interpretation, the case is presented in https://bugs.llvm.org/show_bug.cgi?id=14785: ``` template<typename T> struct Somewhat { void internal() const {} friend void operator+(int const &, Somewhat<T> const &) {} }; void operator+(int const &, Somewhat<char> const &x) { x.internal(); } ``` When statement `x.internal()` in the body of global `operator+` is parsed, the type of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It instantiates the declaration of `operator+` defined inline, and makes a check for redefinition. The check does not detect another definition because the declaration of `operator+` is still not defining as does not have a body yet. To solves this problem the function `isThisDeclarationADefinition` considers a function declaration as a definition if it has flag `WillHaveBody` set. This change fixes PR14785. Differential Revision: https://reviews.llvm.org/D30375 llvm-svn: 305379
* Weaken restriction in r304862 to allow implicit deduction guides to referenceRichard Smith2017-06-081-4/+6
| | | | | | | the injected-class-name of a specialization that uses a partial / explicit specialization. llvm-svn: 304957
* Fix a couple of class template argument deduction crashes with libc++'s tuple.Richard Smith2017-06-071-1/+15
| | | | | | | | | | | | | | | | RecursiveASTVisitor was not properly recursing through a SubstTemplateTypeParmTypes, resulting in crashes in pack expansion where we couldn't always find an unexpanded pack within a pack expansion. We also have an issue where substitution of deduced template arguments for an implicit deduction guide creates the "impossible" case of naming a non-dependent member of the current instantiation, but within a specialization that is actually instantiated from a different (partial/explicit) specialization of the template. We resolve this by declaring that constructors that do so can only be used to deduce specializations of the primary template. I'm running this past CWG to see if people agree this is the right thing to do. llvm-svn: 304862
* Rename RAII objects for performing eager instantiation to have names thatRichard Smith2017-05-201-55/+18
| | | | | | | describe what they're for, not how they do it, and factor out a bit more common code into them. llvm-svn: 303479
* When instantiating a friend function template, don't forget to inherit ↵Richard Smith2017-05-101-0/+13
| | | | | | default template arguments from other declarations. llvm-svn: 302603
* Fix PR32638 : Make sure we switch Sema's CurContext to the substituted ↵Faisal Vali2017-05-091-0/+1
| | | | | | | | | | | | | | | | | | | FunctionDecl when instantiating the exception specification. This fixes the bug: https://bugs.llvm.org/show_bug.cgi?id=32638 int main() { [](auto x) noexcept(noexcept(x)) { } (0); } In the above code, prior to this patch, when substituting into the noexcept expression, i.e. transforming the DeclRefExpr that represents 'x' - clang attempts to capture 'x' because Sema's CurContext is still pointing to the pattern FunctionDecl (i.e. the templated-decl set in FinishTemplateArgumentDeduction) which does not match the substituted 'x's DeclContext, which leads to an attempt to capture and an assertion failure. We fix this by adjusting Sema's CurContext to point to the substituted FunctionDecl under which the noexcept specifier's argument should be transformed, and so the ParmVarDecl that 'x' refers to has the same declcontext and no capture is attempted. I briefly investigated whether the SwitchContext should occur right after VisitMethodDecl creates the new substituted FunctionDecl, instead of only during instantiating the exception specification - but seeing no other code that seemed to rely on that, I decided to leave it just for the duration of the exception specification instantiation. llvm-svn: 302507
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-17/+24
| | | | | | | | - 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
* Clang changes for alloc_align attribute Erich Keane2017-03-301-0/+16
| | | | | | | | GCC has the alloc_align attribute, which is similar to assume_aligned, except the attribute's parameter is the index of the integer parameter that needs aligning to. Differential Revision: https://reviews.llvm.org/D29599 llvm-svn: 299117
* Correct class-template deprecation behavior-REDUXErich Keane2017-03-231-1/+30
| | | | | | | | | | | | | | | | | | 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-31/+1
| | | | | | | 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-1/+31
| | | | | | | | | | | | | 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
* Rename ActiveTemplateInstantiation to CodeSynthesisContext in preparation forRichard Smith2017-02-231-2/+2
| | | | | | | using it for other kinds of context (where we currently produce context notes in a highly ad-hoc manner). llvm-svn: 295919
* Fix lookup through injected-class-names in implicit deduction guides in theRichard Smith2017-02-211-4/+10
| | | | | | | | | | case where the class template has a parameter pack. Checking of the template arguments expects an "as-written" template argument list, which in particular does not have any parameter packs. So flatten the packs into separate arguments before passing them in. llvm-svn: 295710
* PR32010: Fix template argument depth mixup when forming implicit constructorRichard Smith2017-02-211-28/+18
| | | | | | | | | | | | | 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
* Add an explicit derived class of FunctionDecl to model deduction guides ratherRichard Smith2017-02-171-13/+20
| | | | | | | | than just treating them as FunctionDecls with a funny name. No functionality change intended. llvm-svn: 295491
* [VLA] Handle VLA size expression in a full-expression context.Tim Shen2017-02-141-0/+2
| | | | | | | | | | | | | | | | Summary: Previously the cleanups (e.g. dtor calls) are inserted into the outer scope (e.g. function body scope), instead of it's own scope. After the fix, the cleanups are inserted right after getting the size value. This fixes pr30306. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24333 llvm-svn: 295123
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-0/+17
| | | | | | | | | | | | | | | | | | | 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] P0512R0: support for 'explicit' specifier on deduction-guides.Richard Smith2017-02-101-0/+4
| | | | llvm-svn: 294693
* [Sema] Transform a templated name before looking it up inAkira Hatanaka2017-01-311-2/+6
| | | | | | | | | | | | FindInstantiatedDecl or passing it to RebuildMemberExpr. This fixes PR30361. rdar://problem/17341274 Differential Revision: https://reviews.llvm.org/D24969 llvm-svn: 293678
* Towards P0091R3: parsing support for class template argument deduction in ↵Richard Smith2017-01-301-4/+3
| | | | | | | | | 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-3/+4
| | | | | | | | | | | | 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-4/+3
| | | | | | typename-specifiers. llvm-svn: 293455
* Switch the template specialization kind for a non-defining declaration of aRichard Smith2017-01-281-15/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | non-template function instantiated from a friend declaration in a class template from TSK_ImplicitInstantiation to TSK_Undeclared. It doesn't make sense for a non-template function to be flagged as being instantiated from a template; that property really belongs to the entity as a whole and not an individual declaration of it. There's some history here: * r137934 started marking these functions as instantiations in order to work around an issue where we might instantiate a class template while we're still parsing its member definitions, and would otherwise fail to instantiate the friend definition * r177003 fixed the same issue but for friend templates, but did so by making the friends claim to be definitions even before we'd parsed their actual bodies; this made the r137934 change redundant * r293558 worked around a problem caused by the marking of a non-template function as a template instantiation in r137934 This change reverts the code changes from r293358 and r137934 and retains all the tests. llvm-svn: 293367
* -Wunused-func-template: do not warn on non-template function declarations thatRichard Smith2017-01-281-1/+6
| | | | | | | were nonetheless instantiated (particularly, non-template friends declared within class templates). llvm-svn: 293358
* PR31469: Don't add friend template class decls to redecl chain in dependent ↵Vassil Vassilev2017-01-121-2/+4
| | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud