summaryrefslogtreecommitdiffstats
path: root/libcxx/docs/DesignDocs
diff options
context:
space:
mode:
authorShoaib Meenai <smeenai@fb.com>2017-03-02 03:02:50 +0000
committerShoaib Meenai <smeenai@fb.com>2017-03-02 03:02:50 +0000
commitbad28c44eb1df72ede59c1a56e09b4a2f34688c3 (patch)
treee7bf200236551ce5bdd54961aee75ba1923fb664 /libcxx/docs/DesignDocs
parent414fbb4549ca667e31207b8a86499236df7eadbf (diff)
downloadbcm5719-llvm-bad28c44eb1df72ede59c1a56e09b4a2f34688c3.tar.gz
bcm5719-llvm-bad28c44eb1df72ede59c1a56e09b4a2f34688c3.zip
[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
Diffstat (limited to 'libcxx/docs/DesignDocs')
-rw-r--r--libcxx/docs/DesignDocs/VisibilityMacros.rst29
1 files changed, 29 insertions, 0 deletions
diff --git a/libcxx/docs/DesignDocs/VisibilityMacros.rst b/libcxx/docs/DesignDocs/VisibilityMacros.rst
index 12c1d56b366..397dde3ee64 100644
--- a/libcxx/docs/DesignDocs/VisibilityMacros.rst
+++ b/libcxx/docs/DesignDocs/VisibilityMacros.rst
@@ -110,6 +110,35 @@ Visibility Macros
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
OpenPOWER on IntegriCloud