[clang] Add the exclude_from_explicit_instantiation attribute

[ldionne]

Summary

This attribute allows excluding a member of a class template from being part
of an explicit template instantiation of that class template. This also makes
sure that code using such a member will not take for granted that an external
instantiation exists in another translation unit. The attribute was discussed
on cfe-dev at [1] and is primarily motivated by the removal of always_inline
in libc++ to control what's part of the ABI (see links in [1]).

[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html

rdar://problem/43428125

[ldionne]

This patch is an early WIP -- I'm just uploading it to serve as a support for a message I'm about to post on cfe-dev. No need to review seriously for now.

[dexonsmith]

+cfe-commits
-llvm-commits

[rsmith]

It'd be good to test that [[no_extern_template]] affects instantiation, not just code generation (eg, put something in the body of the entity that will trigger an error if instantiated, and check that the diagnostic is produced at the right times).

[ldionne]

Fix the tests and remove some warnings that I wasn't able to generate properly
(to avoid false positives).

[ldionne]

I think now's a good time to bikeshed the name of the attribute if you have other suggestions.

[rsmith]

In D51789#1234903, @ldionne wrote:

I think now's a good time to bikeshed the name of the attribute if you have other suggestions.

OK, so the semantics of this attribute are "explicit instantiation declarations or definitions applied to the enclosing class do not apply to this member", right? So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

Maybe something like exclude_from_explicit_instantiation? That's a little longer than I'd like, but if it's going to be hidden behind a macro most of the time I could live with it.
Or maybe no_transitive_instantiation? That's less explicit about the purpose of the attribute, but is a more comfortable length.

[ldionne]

In D51789#1235096, @rsmith wrote:

In D51789#1234903, @ldionne wrote:

I think now's a good time to bikeshed the name of the attribute if you have other suggestions.

OK, so the semantics of this attribute are "explicit instantiation declarations or definitions applied to the enclosing class do not apply to this member", right? So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

Yes, but it also (obviously) opts the member out when applied to the member itself, not only to an enclosing class.

Maybe something like exclude_from_explicit_instantiation? That's a little longer than I'd like, but if it's going to be hidden behind a macro most of the time I could live with it.

I like this a lot too. I thought about that one and was deterred by the length, but it may be acceptable. Realistically, it's also not an attribute we want people to use most of the time.

Or maybe no_transitive_instantiation? That's less explicit about the purpose of the attribute, but is a more comfortable length.

I'm not sure this one describes what the attribute is doing sufficiently closely.

Unless we get a better suggestion soonish, I'll change it to exclude_from_explicit_instantiation and update the diff.

[rsmith]

In D51789#1235100, @ldionne wrote:

In D51789#1235096, @rsmith wrote:

OK, so the semantics of this attribute are "explicit instantiation declarations or definitions applied to the enclosing class do not apply to this member", right? So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

Yes, but it also (obviously) opts the member out when applied to the member itself, not only to an enclosing class.

Assuming I'm understanding you correctly, I don't think the current implementation does that (nor does the documentation change say that), and I think that's a feature not a bug. For example, given:

template<typename T> struct A {
  [[clang::no_extern_template]] void f() {}
  void g() {}
};
template struct A<int>; // instantiates A<int> and definition of A<int>::g(), does not instantiate definition of A<int>::f()
template void A<int>::f(); // instantiates definition of A<int>::f() despite attribute

... the attribute affects the first explicit instantiation but not the second (I think you're saying it should affect both, and make the second explicit instantiation have no effect). I think the current behavior in this patch is appropriate: making the attribute also affect the second case makes it strictly less useful. If you didn't want to actually explictly instantiate A<int>::f(), you can just leave out that explicit instantiation. But the current implementation gives you extra capabilities:

// A<float>::g() is instantiated somewhere else, A<float>::f() still needs to be implicitly instantiated when used
extern template struct A<float>;

// A<int>::f() and A<int>::g() are both instantiated somewhere else
extern template struct A<int>;
extern template void A<int>::f();

You can't do that if an explicit instantiation of a member with the attribute has no effect.

[ldionne]

In D51789#1235113, @rsmith wrote:

In D51789#1235100, @ldionne wrote:

In D51789#1235096, @rsmith wrote:

OK, so the semantics of this attribute are "explicit instantiation declarations or definitions applied to the enclosing class do not apply to this member", right? So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

Yes, but it also (obviously) opts the member out when applied to the member itself, not only to an enclosing class.

Assuming I'm understanding you correctly, I don't think the current implementation does that (nor does the documentation change say that), and I think that's a feature not a bug. For example, given:

template<typename T> struct A {
  [[clang::no_extern_template]] void f() {}
  void g() {}
};
template struct A<int>; // instantiates A<int> and definition of A<int>::g(), does not instantiate definition of A<int>::f()
template void A<int>::f(); // instantiates definition of A<int>::f() despite attribute

... the attribute affects the first explicit instantiation but not the second (I think you're saying it should affect both, and make the second explicit instantiation have no effect). I think the current behavior in this patch is appropriate: making the attribute also affect the second case makes it strictly less useful. [...]

Sorry, that's a misunderstanding. We're on the same page. What I meant is that if you apply the attribute to the entity itself but explicitly instantiate the enclosing class, then the entity is not instantiated. It's very obvious, but your previous comment:

So it opts the member out of both extern template and (non-extern) template, but only when applied to an enclosing class.

suggested that it only applied in the following case:

template <class T> struct Foo {
  struct __attribute__((no_extern_template)) nested { static void f() { } };
};

template struct Foo<int>; // Foo<int>::nested::f not instantiated

[ldionne]

Change no_extern_template to exclude_from_explicit_instantiation

[rsmith]

Looks good other than the warning, which I don't yet understand.

clang/include/clang/Basic/DiagnosticSemaKinds.td

4683–4686

Diagnostics should start with a lowercase letter and not end with a period.

That said, I'm not sure I see why this diagnostic is correct / useful. If the entity is never used, then there's no link error. And if it is ever used, then you should get an implicit instantiation like normal, and we already have a diagnostic for the case where an entity is implicitly instantiated and no definition is available.

clang/lib/Sema/SemaTemplateInstantiate.cpp

2579–2580

Nit: we prefer to left-align continuation lines (clang-format will do that for you).

[ldionne]

clang/include/clang/Basic/DiagnosticSemaKinds.td

4683–4686

Diagnostics should start with a lowercase letter and not end with a period.

Done.

That said, I'm not sure I see why this diagnostic is correct / useful. If the entity is never used, then there's no link error. And if it is ever used, then you should get an implicit instantiation like normal, and we already have a diagnostic for the case where an entity is implicitly instantiated and no definition is available.

This is not what happens right now. If you don't provide a definition but you try to call the function, an extern call will be produced (and that will result in a link error because any potential explicit instantiation won't provide the function). For example:

cat <<EOF | ./install/bin/clang++ -cc1 -stdlib=libc++ -xc++ -emit-llvm -o - -
template <class T>
struct Foo {
  __attribute__((exclude_from_explicit_instantiation)) static void static_member_function();
};

extern template struct Foo<int>;

int main() {
  Foo<int>::static_member_function();
}
EOF

Results in the following LLVM IR:

; Function Attrs: noinline norecurse nounwind optnone
define i32 @main() #0 {
entry:
  call void @_ZN3FooIiE22static_member_functionEv()
  ret i32 0
}

declare void @_ZN3FooIiE22static_member_functionEv() #1

I guess we should be getting a warning or an error on the point of implicit instantiation instead, or is this behavior acceptable?

clang/lib/Sema/SemaTemplateInstantiate.cpp

2579–2580

Thanks for the heads up. I ran clang-format on all the lines I touched in this file.

[ldionne]

Reformat warning message and run clang-format on changed lines.

[aaron.ballman]

clang/include/clang/Basic/AttrDocs.td

2990

An example that demonstrates how the attribute behaves would be appreciated. Having some exposition that explains why a user might want to write this attribute themselves would also be good.

[ldionne]

Add example of how to use the attribute, per Aaron's comment.

[ldionne]

I'm thinking about this some more, and I'm wondering whether it would be a viable solution to just exclude members marked with hidden visibility from explicit template instantiations (and declarations thereof). I thought I had been convinced by Hubert that visibility and this attribute should be left separate, but now I'm not sure anymore. I don't think there's a single case of a member function with hidden visibility that we don't want to exclude from explicit instantiations. @rsmith Thoughts?

[rjmccall]

That may work for libc++'s purposes, but it's clearly inappropriate as a compiler rule. There are good reasons why something with hidden visibility would need to be explicitly instantiated. For many programmers, hidden visibility means "this is private to my library", not "this is actually public to my library, but I'm walking an ABI tightrope".

[ldionne]

In D51789#1238396, @rjmccall wrote:

That may work for libc++'s purposes, but it's clearly inappropriate as a compiler rule. There are good reasons why something with hidden visibility would need to be explicitly instantiated.

I take your word for it, but I can't think of any example. For my education, do you have a specific example in mind?

For many programmers, hidden visibility means "this is private to my library", not "this is actually public to my library, but I'm walking an ABI tightrope".

In libc++'s case, the functions we will annotate with exclude_from_explicit_instantiation are private to libc++ too (in the sense that we don't want them part of the ABI and they are not exported from the dylib). Those functions were previously marked with __always_inline__ to make sure they were not part of the ABI.

Note that I'm quite happy with exclude_from_explicit_instantiation as it solves libc++'s problem -- I'm trying to see whether another solution would serve people better while still solving libc++'s problem. (Appart from explicitly exporting functions, typeinfos and vtables like we've talked about on cfe-dev, which is a superior solution to everything else but is left as a future improvement for the time being).

[rjmccall]

In D51789#1238410, @ldionne wrote:

In D51789#1238396, @rjmccall wrote:

That may work for libc++'s purposes, but it's clearly inappropriate as a compiler rule. There are good reasons why something with hidden visibility would need to be explicitly instantiated.

I take your word for it, but I can't think of any example. For my education, do you have a specific example in mind?

I mean, most code doesn't use explicit instantiations to begin with, but — the general idea would be someone using an explicit instantiation, either for compile-time or seperate-compilation reasons, for some type that's entirely private to their library.

Here's an example of it from Swift that happened to be easy to find:

https://github.com/apple/swift/blob/master/lib/SILOptimizer/ARC/RCStateTransitionVisitors.h

The entire template being instantiated there is private to the SILOptimizer library. Swift doesn't use explicit visibility attributes much, preferring to globally assume -fvisibility=hidden, but if we used them, there would definitely be an attribute on that template.

For many programmers, hidden visibility means "this is private to my library", not "this is actually public to my library, but I'm walking an ABI tightrope".

In libc++'s case, the functions we will annotate with exclude_from_explicit_instantiation are private to libc++ too (in the sense that we don't want them part of the ABI and they are not exported from the dylib). Those functions were previously marked with __always_inline__ to make sure they were not part of the ABI.

Yeah, I understand the use case. That's what I was calling an ABI tightrope. The functions you're annotating are still part of libc++'s *logical* interface, they're just not exported by the dylib.

Note that I'm quite happy with exclude_from_explicit_instantiation as it solves libc++'s problem -- I'm trying to see whether another solution would serve people better while still solving libc++'s problem. (Appart from explicitly exporting functions, typeinfos and vtables like we've talked about on cfe-dev, which is a superior solution to everything else but is left as a future improvement for the time being).

Understood.

John.

[rsmith]

clang/include/clang/Basic/DiagnosticSemaKinds.td

4683–4686

I don't think your example is fundamentally any different from:

template <class T>
struct Foo {
  static void static_member_function();
};

int main() {
  Foo<int>::static_member_function();
}

which likewise produces a declaration of _ZN3FooIiE22static_member_functionEv. That case produces a -Wundefined-func-template warning; your example should do the same.

[ldionne]

Fix warnings on undefined entities

[rsmith]

clang/lib/Sema/Sema.cpp

648 ↗

(On Diff #166590)

What's the purpose of this change?

clang/test/SemaCXX/attr-exclude_from_explicit_instantiation.diagnose_on_undefined_entity.cpp

30

I generally prefer to use relative line numbers (@-5) rather than absolute ones, so that the test doesn't break if unrelated things are changed earlier in the file.

[ldionne]

clang/lib/Sema/Sema.cpp

648 ↗

(On Diff #166590)

It's so that we diagnose a member function marked with exclude_from_explicit_instantiation that is used but not defined just like we do for an inline function. This causes us to push_back the declaration (line 668 below) into the vector of Undefined-but-used declarations, which we use to trigger a diagnostic somewhere else.

clang/include/clang/Basic/Attr.td

 }
 
 def InternalLinkage : InheritableAttr {
   let Spellings = [Clang<"internal_linkage">];
   let Subjects = SubjectList<[Var, Function, CXXRecord]>;
   let Documentation = [InternalLinkageDocs];
 }
 
+def ExcludeFromExplicitInstantiation : InheritableAttr {
+  let Spellings = [Clang<"exclude_from_explicit_instantiation">];
+  let Subjects = SubjectList<[Var, Function, CXXRecord]>;
+  let Documentation = [ExcludeFromExplicitInstantiationDocs];
+  let MeaningfulToClassTemplateDefinition = 1;
+}
+
 def Reinitializes : InheritableAttr {
   let Spellings = [Clang<"reinitializes", 0>];
   let Subjects = SubjectList<[NonStaticNonConstCXXMethod], ErrorDiag>;
   let Documentation = [ReinitializesDocs];
 }
 
 def NoDestroy : InheritableAttr {
   let Spellings = [Clang<"no_destroy", 0>];

clang/include/clang/Basic/AttrDocs.td

def InternalLinkageDocs : Documentation {
   let Content = [{
 The ``internal_linkage`` attribute changes the linkage type of the declaration to internal.
 This is similar to C-style ``static``, but can be used on classes and class methods. When applied to a class definition,
 this attribute affects all methods and static data members of that class.
 This can be used to contain the ABI of a C++ library by excluding unwanted class methods from the export tables.
   }];
 }
 
+def ExcludeFromExplicitInstantiationDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``exclude_from_explicit_instantiation`` attribute opts-out a member of a
+class template from being part of explicit template instantiations of that
+class template. This means that an explicit instantiation will not instantiate
+members of the class template marked with the attribute, but also that code
+where an extern template declaration of the enclosing class template is visible
+will not take for granted that an external instantiation of the class template
+would provide those members (which would otherwise be a link error, since the
+explicit instantiation won't provide those members). For example, let's say we
+don't want the ``data()`` method to be part of libc++'s ABI. To make sure it
+is not exported from the dylib, we give it hidden visibility:
+
+  .. code-block:: c++
+
+    // in <string>
+    template <class CharT>
+    class basic_string {
+    public:
+      __attribute__((__visibility__("hidden")))
+      const value_type* data() const noexcept { ... }
+    };
+
+    template class basic_string<char>;
+
+Since an explicit template instantiation declaration for ``basic_string<char>``
+is provided, the compiler is free to assume that ``basic_string<char>::data()``
+will be provided by another translation unit, and it is free to produce an
+external call to this function. However, since ``data()`` has hidden visibility
+and the explicit template instantiation is provided in a shared library (as
+opposed to simply another translation unit), ``basic_string<char>::data()``
+won't be found and a link error will ensue. This happens because the compiler
+assumes that ``basic_string<char>::data()`` is part of the explicit template
+instantiation declaration, when it really isn't. To tell the compiler that
+``data()`` is not part of the explicit template instantiation declaration, the
+``exclude_from_explicit_instantiation`` attribute can be used:
+
+  .. code-block:: c++
+
+    // in <string>
+    template <class CharT>
+    class basic_string {
+    public:
+      __attribute__((__visibility__("hidden")))
+      __attribute__((exclude_from_explicit_instantiation))
+      const value_type* data() const noexcept { ... }
+    };
+
+    template class basic_string<char>;
+
+Now, the compiler won't assume that ``basic_string<char>::data()`` is provided
+externally despite there being an explicit template instantiation declaration:
+the compiler will implicitly instantiate ``basic_string<char>::data()`` in the
+TUs where it is used.
+
+This attribute can be used on static and non-static member functions of class
+templates, static data members of class templates and member classes of class
+templates.
+  }];
+}
+
 def DisableTailCallsDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``disable_tail_calls`` attribute instructs the backend to not perform tail call optimization inside the marked function.
 
 For example:
 
   .. code-block:: c

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def note_used_here : Note<"used here">;
 
 def err_internal_linkage_redeclaration : Error<
   "'internal_linkage' attribute does not appear on the first declaration of %0">;
 def warn_internal_linkage_local_storage : Warning<
   "'internal_linkage' attribute on a non-static local variable is ignored">,
   InGroup<IgnoredAttributes>;
 
+def warn_exclude_from_explicit_instantiation_undefined_entity : Warning<
+  "member '%0' marked with 'exclude_from_explicit_instantiation' attribute is "
+  "not defined but an explicit template instantiation declaration exists: "
+  "reliance on this member being defined by an explicit template instantiation "
+  "will lead to link errors">;
+def note_explicit_template_instantiation_declaration_here: Note<
+  "explicit template instantiation declaration is here">;
+
 def ext_internal_in_extern_inline : ExtWarn<
   "static %select{function|variable}0 %1 is used in an inline function with "
   "external linkage">, InGroup<StaticInInline>;
 def ext_internal_in_extern_inline_quiet : Extension<
   "static %select{function|variable}0 %1 is used in an inline function with "
   "external linkage">, InGroup<StaticInInline>;
 def warn_static_local_in_extern_inline : Warning<
   "non-constant static local variable in inline function may be different "

clang/lib/Sema/SemaDeclAttr.cpp

case ParsedAttr::AT_SwiftErrorResult:
     handleParameterABIAttr(S, D, AL, ParameterABI::SwiftErrorResult);
     break;
   case ParsedAttr::AT_SwiftIndirectResult:
     handleParameterABIAttr(S, D, AL, ParameterABI::SwiftIndirectResult);
     break;
   case ParsedAttr::AT_InternalLinkage:
     handleInternalLinkageAttr(S, D, AL);
     break;
+  case ParsedAttr::AT_ExcludeFromExplicitInstantiation:
+    handleSimpleAttribute<ExcludeFromExplicitInstantiationAttr>(S, D, AL);
+    break;
   case ParsedAttr::AT_LTOVisibilityPublic:
     handleSimpleAttribute<LTOVisibilityPublicAttr>(S, D, AL);
     break;
 
   // Microsoft attributes:
   case ParsedAttr::AT_EmptyBases:
     handleSimpleAttribute<EmptyBasesAttr>(S, D, AL);
     break;

clang/lib/Sema/SemaTemplateInstantiate.cpp

Sema::InstantiateClassMembers(SourceLocation PointOfInstantiation,
   assert(
       (TSK == TSK_ExplicitInstantiationDefinition ||
        TSK == TSK_ExplicitInstantiationDeclaration ||
        (TSK == TSK_ImplicitInstantiation && Instantiation->isLocalClass())) &&
       "Unexpected template specialization kind!");
   for (auto *D : Instantiation->decls()) {
     bool SuppressNew = false;
     if (auto *Function = dyn_cast<FunctionDecl>(D)) {
-      if (FunctionDecl *Pattern
-            = Function->getInstantiatedFromMemberFunction()) {
-        MemberSpecializationInfo *MSInfo
-          = Function->getMemberSpecializationInfo();
+      if (FunctionDecl *Pattern =
+              Function->getInstantiatedFromMemberFunction()) {
+
+        if (Function->hasAttr<ExcludeFromExplicitInstantiationAttr>()) {
+          if (TSK == TSK_ExplicitInstantiationDeclaration &&
+              !Pattern->isDefined()) {
+            Diag(
+                Function->getLocation(),
+                diag::warn_exclude_from_explicit_instantiation_undefined_entity)
+                << Function->getName();
+            Diag(PointOfInstantiation,
+                 diag::note_explicit_template_instantiation_declaration_here);
+          }
+          continue;
+        }
+
+        MemberSpecializationInfo *MSInfo =
+            Function->getMemberSpecializationInfo();
         assert(MSInfo && "No member specialization information?");
         if (MSInfo->getTemplateSpecializationKind()
                                                  == TSK_ExplicitSpecialization)
           continue;
 
         if (CheckSpecializationInstantiationRedecl(PointOfInstantiation, TSK,
                                                    Function,
                                         MSInfo->getTemplateSpecializationKind(),
if (auto *Function = dyn_cast<FunctionDecl>(D)) {
               std::make_pair(Function, PointOfInstantiation));
         }
       }
     } else if (auto *Var = dyn_cast<VarDecl>(D)) {
       if (isa<VarTemplateSpecializationDecl>(Var))
         continue;
 
       if (Var->isStaticDataMember()) {
+        if (Var->hasAttr<ExcludeFromExplicitInstantiationAttr>()) {
+          if (TSK == TSK_ExplicitInstantiationDeclaration &&
+              !Var->getInstantiatedFromStaticDataMember()->getDefinition()) {
+            Diag(
+                Var->getLocation(),
+                diag::warn_exclude_from_explicit_instantiation_undefined_entity)
+                << Var->getName();
+            Diag(PointOfInstantiation,
+                 diag::note_explicit_template_instantiation_declaration_here);
+          }
+          continue;
+        }
+
         MemberSpecializationInfo *MSInfo = Var->getMemberSpecializationInfo();
         assert(MSInfo && "No member specialization information?");
         if (MSInfo->getTemplateSpecializationKind()
                                                  == TSK_ExplicitSpecialization)
           continue;
 
         if (CheckSpecializationInstantiationRedecl(PointOfInstantiation, TSK,
                                                    Var,
if (auto *Function = dyn_cast<FunctionDecl>(D)) {
 
           Var->setTemplateSpecializationKind(TSK, PointOfInstantiation);
           InstantiateVariableDefinition(PointOfInstantiation, Var);
         } else {
           Var->setTemplateSpecializationKind(TSK, PointOfInstantiation);
         }
       }
     } else if (auto *Record = dyn_cast<CXXRecordDecl>(D)) {
+      if (Record->hasAttr<ExcludeFromExplicitInstantiationAttr>()) {
+        if (TSK == TSK_ExplicitInstantiationDeclaration &&
+            !Record->getDefinition() &&
+            !Record->getInstantiatedFromMemberClass()->getDefinition()) {
+          Diag(Record->getLocation(),
+               diag::warn_exclude_from_explicit_instantiation_undefined_entity)
+              << Record->getName();
+          Diag(PointOfInstantiation,
+               diag::note_explicit_template_instantiation_declaration_here);
+        }
+        continue;
+      }
+
       // Always skip the injected-class-name, along with any
       // redeclarations of nested classes, since both would cause us
       // to try to instantiate the members of a class twice.
       // Skip closure types; they'll get instantiated when we instantiate
       // the corresponding lambda-expression.
       if (Record->isInjectedClassName() || Record->getPreviousDecl() ||
           Record->isLambda())
         continue;

clang/test/CodeGenCXX/attr-exclude_from_explicit_instantiation.dont_assume_extern_instantiation.cpp

+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -O0 -o - %s | FileCheck %s
+
+// Test that we do not assume that entities marked with the
+// exclude_from_explicit_instantiation attribute are instantiated
+// in another TU when an extern template instantiation declaration
+// is present. We test that by making sure that definitions are
+// generated in this TU despite there being an extern template
+// instantiation declaration, which is normally not the case.
+
+#define EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((exclude_from_explicit_instantiation))
+
+template <class T>
+struct Foo {
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION        inline void non_static_member_function1();
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION               void non_static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static inline void static_member_function1();
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static        void static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static        int static_data_member;
+
+  struct EXCLUDE_FROM_EXPLICIT_INSTANTIATION member_class1 {
+    static void static_member_function() { }
+  };
+
+  struct member_class2 {
+    EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void static_member_function() { }
+  };
+};
+
+template <class T> inline void Foo<T>::non_static_member_function1() { }
+template <class T>        void Foo<T>::non_static_member_function2() { }
+
+template <class T> inline void Foo<T>::static_member_function1() { }
+template <class T>        void Foo<T>::static_member_function2() { }
+
+template <class T>        int Foo<T>::static_data_member = 0;
+
+extern template struct Foo<int>;
+
+void use() {
+  Foo<int> f;
+
+  // An inline non-static member function marked with the attribute is not
+  // part of the extern template declaration, so a definition must be emitted
+  // in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE27non_static_member_function1Ev
+  f.non_static_member_function1();
+
+  // A non-inline non-static member function marked with the attribute is
+  // not part of the extern template declaration, so a definition must be
+  // emitted in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE27non_static_member_function2Ev
+  f.non_static_member_function2();
+
+  // An inline static member function marked with the attribute is not
+  // part of the extern template declaration, so a definition must be
+  // emitted in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE23static_member_function1Ev
+  Foo<int>::static_member_function1();
+
+  // A non-inline static member function marked with the attribute is not
+  // part of the extern template declaration, so a definition must be
+  // emitted in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE23static_member_function2Ev
+  Foo<int>::static_member_function2();
+
+  // A static data member marked with the attribute is not part of the
+  // extern template declaration, so a definition must be emitted in this TU.
+  // CHECK-DAG: @_ZN3FooIiE18static_data_memberE = linkonce_odr global
+  int& odr_use = Foo<int>::static_data_member;
+
+  // A member class marked with the attribute is not part of the extern
+  // template declaration (it is not recursively instantiated), so its member
+  // functions must be emitted in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE13member_class122static_member_functionEv
+  Foo<int>::member_class1::static_member_function();
+
+  // A member function marked with the attribute in a member class is not
+  // part of the extern template declaration of the parent class template, so
+  // it must be emitted in this TU.
+  // CHECK-DAG: define linkonce_odr void @_ZN3FooIiE13member_class222static_member_functionEv
+  Foo<int>::member_class2::static_member_function();
+}

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // RUN: clang-tblgen -gen-clang-test-pragma-attribute-supported-attributes -I%src_include_dir %src_include_dir/clang/Basic/Attr.td -o - | FileCheck %s
 
 // The number of supported attributes should never go down!
 
-// CHECK: #pragma clang attribute supports 128 attributes:
+// CHECK: #pragma clang attribute supports 129 attributes:
 // CHECK-NEXT: AMDGPUFlatWorkGroupSize (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumSGPR (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUNumVGPR (SubjectMatchRule_function)
 // CHECK-NEXT: AMDGPUWavesPerEU (SubjectMatchRule_function)
 // CHECK-NEXT: AVRSignal (SubjectMatchRule_function)
 // CHECK-NEXT: AbiTag (SubjectMatchRule_record_not_is_union, SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_namespace)
 // CHECK-NEXT: Alias (SubjectMatchRule_function, SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: AlignValue (SubjectMatchRule_variable, SubjectMatchRule_type_alias)

 // CHECK-NEXT: ConsumableSetOnRead (SubjectMatchRule_record)
 // CHECK-NEXT: Convergent (SubjectMatchRule_function)
 // CHECK-NEXT: DLLExport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: DLLImport (SubjectMatchRule_function, SubjectMatchRule_variable, SubjectMatchRule_record, SubjectMatchRule_objc_interface)
 // CHECK-NEXT: Destructor (SubjectMatchRule_function)
 // CHECK-NEXT: DisableTailCalls (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: EnableIf (SubjectMatchRule_function)
 // CHECK-NEXT: EnumExtensibility (SubjectMatchRule_enum)
+// CHECK-NEXT: ExcludeFromExplicitInstantiation (SubjectMatchRule_variable, SubjectMatchRule_function, SubjectMatchRule_record)
 // CHECK-NEXT: ExternalSourceSymbol ((SubjectMatchRule_record, SubjectMatchRule_enum, SubjectMatchRule_enum_constant, SubjectMatchRule_field, SubjectMatchRule_function, SubjectMatchRule_namespace, SubjectMatchRule_objc_category, SubjectMatchRule_objc_interface, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_objc_protocol, SubjectMatchRule_record, SubjectMatchRule_type_alias, SubjectMatchRule_variable))
 // CHECK-NEXT: FlagEnum (SubjectMatchRule_enum)
 // CHECK-NEXT: Flatten (SubjectMatchRule_function)
 // CHECK-NEXT: GNUInline (SubjectMatchRule_function)
 // CHECK-NEXT: Hot (SubjectMatchRule_function)
 // CHECK-NEXT: IBAction (SubjectMatchRule_objc_method_is_instance)
 // CHECK-NEXT: IFunc (SubjectMatchRule_function)
 // CHECK-NEXT: InitPriority (SubjectMatchRule_variable)

clang/test/SemaCXX/attr-exclude_from_explicit_instantiation.diagnose_on_undefined_entity.cpp

+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Test that a diagnostic is emitted when an entity marked with the
+// exclude_from_explicit_instantiation attribute is not defined in
+// the current TU but an extern template declaration for the enclosing
+// class exists.
+
+#define EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((exclude_from_explicit_instantiation))
+
+template <class T>
+struct Foo {
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION void non_static_member_function();     // expected-warning{{member 'non_static_member_function' marked with 'exclude_from_explicit_instantiation' attribute is not defined but an explicit template instantiation declaration exists: reliance on this member being defined by an explicit template instantiation will lead to link errors}}
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void static_member_function(); // expected-warning{{member 'static_member_function' marked with 'exclude_from_explicit_instantiation' attribute is not defined}}
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static int static_data_member;         // expected-warning{{member 'static_data_member' marked with 'exclude_from_explicit_instantiation' attribute is not defined}}
+  struct EXCLUDE_FROM_EXPLICIT_INSTANTIATION member_class1;                  // expected-warning{{member 'member_class1' marked with 'exclude_from_explicit_instantiation' attribute is not defined}}
+};
+
+extern template struct Foo<int>; // expected-note 4 {{explicit template instantiation declaration is here}}

clang/test/SemaCXX/attr-exclude_from_explicit_instantiation.explicit_instantiation.cpp

+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Test that explicit instantiations do not instantiate entities
+// marked with the exclude_from_explicit_instantiation attribute.
+
+#define EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((exclude_from_explicit_instantiation))
+
+template <class T>
+struct Foo {
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION inline void non_static_member_function1();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION void non_static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static inline void static_member_function1();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static int static_data_member;
+
+  struct EXCLUDE_FROM_EXPLICIT_INSTANTIATION member_class1 {
+    static void non_static_member_function() { using Fail = typename T::fail; }
+  };
+
+  struct member_class2 {
+    EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void non_static_member_function() { using Fail = typename T::fail; }
+  };
+};
+
+template <class T>
+inline void Foo<T>::non_static_member_function1() { using Fail = typename T::fail; }
+
+template <class T>
+void Foo<T>::non_static_member_function2() { using Fail = typename T::fail; }
+
+template <class T>
+inline void Foo<T>::static_member_function1() { using Fail = typename T::fail; }
+
+template <class T>
+void Foo<T>::static_member_function2() { using Fail = typename T::fail; }
+
+template <class T>
+int Foo<T>::static_data_member = T::fail;
+
+// expected-no-diagnostics
+template struct Foo<int>;

clang/test/SemaCXX/attr-exclude_from_explicit_instantiation.extern_declaration.cpp

+// RUN: %clang_cc1 -Wno-unused-local-typedef -fsyntax-only -verify %s
+
+// Test that extern instantiation declarations cause members marked with
+// the exclude_from_explicit_instantiation attribute to be instantiated in
+// the current TU.
+
+#define EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((exclude_from_explicit_instantiation))
+
+template <class T>
+struct Foo {
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION inline void non_static_member_function1();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION void non_static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static inline void static_member_function1();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void static_member_function2();
+
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION static int static_data_member;
+
+  struct EXCLUDE_FROM_EXPLICIT_INSTANTIATION member_class1 {
+    static void static_member_function() {
+      using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+    }
+  };
+
+  struct member_class2 {
+    EXCLUDE_FROM_EXPLICIT_INSTANTIATION static void static_member_function() {
+      using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+    }
+  };
+};
+
+template <class T>
+inline void Foo<T>::non_static_member_function1() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+void Foo<T>::non_static_member_function2() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+inline void Foo<T>::static_member_function1() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+void Foo<T>::static_member_function2() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+int Foo<T>::static_data_member = T::invalid; // expected-error{{no member named 'invalid' in 'Empty'}}
+
+struct Empty { };
+extern template struct Foo<Empty>;
+
+int main() {
+  Foo<Empty> foo;
+  foo.non_static_member_function1();                   // expected-note{{in instantiation of}}
+  foo.non_static_member_function2();                   // expected-note{{in instantiation of}}
+  Foo<Empty>::static_member_function1();               // expected-note{{in instantiation of}}
+  Foo<Empty>::static_member_function2();               // expected-note{{in instantiation of}}
+  (void)foo.static_data_member;                        // expected-note{{in instantiation of}}
+  Foo<Empty>::member_class1::static_member_function(); // expected-note{{in instantiation of}}
+  Foo<Empty>::member_class2::static_member_function(); // expected-note{{in instantiation of}}
+}

clang/test/SemaCXX/attr-exclude_from_explicit_instantiation.merge_redeclarations.cpp

+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Test that we properly merge the exclude_from_explicit_instantiation
+// attribute on redeclarations.
+
+#define EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((exclude_from_explicit_instantiation))
+
+template <class T>
+struct Foo {
+  // Declaration without the attribute, definition with the attribute.
+  void func1();
+
+  // Declaration with the attribute, definition without the attribute.
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION void func2();
+
+  // Declaration with the attribute, definition with the attribute.
+  EXCLUDE_FROM_EXPLICIT_INSTANTIATION void func3();
+};
+
+template <class T>
+EXCLUDE_FROM_EXPLICIT_INSTANTIATION void Foo<T>::func1() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+void Foo<T>::func2() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+template <class T>
+EXCLUDE_FROM_EXPLICIT_INSTANTIATION void Foo<T>::func3() {
+  using Fail = typename T::invalid; // expected-error{{no type named 'invalid' in 'Empty'}}
+}
+
+struct Empty { };
+extern template struct Foo<Empty>;
+
+int main() {
+  Foo<Empty> foo;
+  foo.func1(); // expected-note{{in instantiation of}}
+  foo.func2(); // expected-note{{in instantiation of}}
+  foo.func3(); // expected-note{{in instantiation of}}
+}