[libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export members
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
Cr-Mirrored-From: sso://chromium.googlesource.com/_direct/external/github.com/llvm/llvm-project
Cr-Mirrored-Commit: bad28c44eb1df72ede59c1a56e09b4a2f34688c3
diff --git a/docs/DesignDocs/VisibilityMacros.rst b/docs/DesignDocs/VisibilityMacros.rst
index 12c1d56..397dde3 100644
--- a/docs/DesignDocs/VisibilityMacros.rst
+++ b/docs/DesignDocs/VisibilityMacros.rst
@@ -110,6 +110,35 @@
the extern template declaration) as exported on Windows, as discussed above.
On all other platforms, this macro has an empty definition.
+**_LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS**
+ Mark a symbol as hidden so it will not be exported from shared libraries. This
+ is intended specifically for method templates of either classes marked with
+ `_LIBCPP_TYPE_VIS` or classes with an extern template instantiation
+ declaration marked with `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS`.
+
+ When building libc++ with hidden visibility, we want explicit template
+ instantiations to export members, which is consistent with existing Windows
+ behavior. We also want classes annotated with `_LIBCPP_TYPE_VIS` to export
+ their members, which is again consistent with existing Windows behavior.
+ Both these changes are necessary for clients to be able to link against a
+ libc++ DSO built with hidden visibility without encountering missing symbols.
+
+ An unfortunate side effect, however, is that method templates of classes
+ either marked `_LIBCPP_TYPE_VIS` or with extern template instantiation
+ declarations marked with `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` also get default
+ visibility when instantiated. These methods are often implicitly instantiated
+ inside other libraries which use the libc++ headers, and will therefore end up
+ being exported from those libraries, since those implicit instantiations will
+ receive default visibility. This is not acceptable for libraries that wish to
+ control their visibility, and led to PR30642.
+
+ Consequently, all such problematic method templates are explicitly marked
+ either hidden (via this macro) or inline, so that they don't leak into client
+ libraries. The problematic methods were found by running
+ `bad-visibility-finder <https://github.com/smeenai/bad-visibility-finder>`_
+ against the libc++ headers after making `_LIBCPP_TYPE_VIS` and
+ `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` expand to default visibility.
+
**_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY**
Mark a member function of a class template as visible and always inline. This
macro should only be applied to member functions of class templates that are