summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Remove redundant passing around of a "ContainsAutoType" flag.Richard Smith2017-01-121-4/+3
| | | | | | | | | | | | This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
* Add the diagnose_if attribute to clang.George Burgess IV2017-01-091-19/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `diagnose_if` can be used to have clang emit either warnings or errors for function calls that meet user-specified conditions. For example: ``` constexpr int foo(int a) __attribute__((diagnose_if(a > 10, "configurations with a > 10 are " "expensive.", "warning"))); int f1 = foo(9); int f2 = foo(10); // warning: configuration with a > 10 are expensive. int f3 = foo(f2); ``` It currently only emits diagnostics in cases where the condition is guaranteed to always be true. So, the following code will emit no warnings: ``` constexpr int bar(int a) { foo(a); return 0; } constexpr int i = bar(10); ``` We hope to support optionally emitting diagnostics for cases like that (and emitting runtime checks) in the future. Release notes will appear shortly. :) Differential Revision: https://reviews.llvm.org/D27424 llvm-svn: 291418
* Fix buildbots.Richard Smith2017-01-071-1/+1
| | | | llvm-svn: 291360
* Consistently use a ConstantEvaluated context for expressions in attributes,Richard Smith2017-01-071-1/+2
| | | | | | except for those with the "attributes are unevaluated contexts" flag. llvm-svn: 291358
* [MS] Instantiate default args during instantiation of exported default ctorsReid Kleckner2017-01-051-4/+31
| | | | | | | | | | | | | | | | | | | | Summary: Replace some old code that probably pre-dated the change to delay emission of dllexported code until after the closing brace of the outermost record type. Only uninstantiated default argument expressions need to be handled now. It is enough to instantiate default argument expressions when instantiating dllexported default ctors. This also fixes some double-diagnostic issues in this area. Fixes PR31500 Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28274 llvm-svn: 291045
* Only instantiate members of nested classes in local classes once, rather ↵Richard Smith2017-01-041-2/+5
| | | | | | than once per enclosing class. llvm-svn: 291034
* Mark 'auto' as dependent when instantiating the type of a non-type templateRichard Smith2016-12-281-13/+13
| | | | | | | 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-0/+18
| | | | | | | | | | 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
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-201-59/+134
| | | | | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. This is a re-commit of r290080 (reverted in r290092) with a fix for a use-after-lifetime bug. llvm-svn: 290203
* Revert "[c++1z] P0195R2: Support pack-expansion of using-declarations."Daniel Jasper2016-12-191-134/+59
| | | | | | | This reverts commit r290080 as it leads to many Clang crashes, e.g.: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814 llvm-svn: 290092
* [c++1z] P0195R2: Support pack-expansion of using-declarations.Richard Smith2016-12-191-59/+134
| | | | | | | | | | | This change introduces UsingPackDecl as a marker for the set of UsingDecls produced by pack expansion of a single (unresolved) using declaration. This is not strictly necessary (we just need to be able to map from the original using declaration to its expansions somehow), but it's useful to maintain the invariant that each declaration reference instantiates to refer to one declaration. llvm-svn: 290080
* Fix some interactions between C++11 and C++14 features and using-declarations:Richard Smith2016-12-181-23/+27
| | | | | | | | | | | * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
* [Sema] Set range end of constructors and destructors in template instantiationsMalcolm Parsons2016-11-281-0/+2
| | | | | | | | | | | | | | | | | | Summary: clang-tidy checks frequently use source ranges of functions. The source range of constructors and destructors in template instantiations is currently a single token. The factory method for constructors and destructors does not allow the end source location to be specified. Set end location manually after creating instantiation. Reviewers: aaron.ballman, rsmith, arphaman Subscribers: arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D26849 llvm-svn: 288025
* [Sema] Fix a bug in enable_if condition instantiation.George Burgess IV2016-11-171-3/+2
| | | | | | | | | | | During template instantiation, we currently fall back to just calling Sema::SubstExpr for enable_if attributes that aren't value-dependent or type-dependent. Since Sema::SubstExpr strips off any implicit casts we've added to an expression, it's possible that this behavior will leave us with an enable_if condition that's just a DeclRefExpr. Conditions like that deeply confuse Sema::CheckEnableIf. llvm-svn: 287187
* Fix PR28366: Handle variables from enclosing local scopes more gracefully ↵Faisal Vali2016-11-131-1/+1
| | | | | | | | | | | | | | | | | | during constant expression evaluation. Only look for a variable's value in the constant expression evaluation activation frame, if the variable was indeed declared in that frame, otherwise it might be a constant expression and be usable within a nested local scope or emit an error. void f(char c) { struct X { static constexpr char f() { return c; // error gracefully here as opposed to crashing. } }; int I = X::f(); } llvm-svn: 286748
* Reinstate r284008 reverted in r284081, with two fixes:Richard Smith2016-10-141-22/+18
| | | | | | | | | | | | | | | | | | | 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-18/+22
| | | | | | cases. I'm working on reducing a testcase. llvm-svn: 284081
* Reinstate r283887 and r283882.Vassil Vassilev2016-10-121-22/+18
| | | | | | | | | | | 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-18/+22
| | | | llvm-svn: 283890
* [modules] PR28752: Do not instantiate variable declarations which are not ↵Vassil Vassilev2016-10-111-22/+18
| | | | | | | | | | visible. https://reviews.llvm.org/D24508 Patch developed in collaboration with Richard Smith! llvm-svn: 283882
OpenPOWER on IntegriCloud