Commit Graph

22 Commits

Author SHA1 Message Date
Mehdi Amini e9c66ad9fa Add markup for libc++ dylib availability
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.

See docs/DesignDocs/AvailabilityMarkup.rst for more information.

Differential Revision: https://reviews.llvm.org/D31739

llvm-svn: 302172
2017-05-04 17:08:54 +00:00
Shoaib Meenai bda3c7df78 [libc++] Make _LIBCPP_TYPE_VIS export members
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.

With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.

The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.

[1] https://github.com/smeenai/bad-visibility-finder

Reviewers: mclow.lists, EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25208

llvm-svn: 296732
2017-03-02 03:22:18 +00:00
Shoaib Meenai bad28c44eb [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
2017-03-02 03:02:50 +00:00
Eric Fiselier cd1703b241 Fix typo in docs
llvm-svn: 294115
2017-02-05 01:16:25 +00:00
Eric Fiselier fc26379a84 [libc++] Introduce _LIBCPP_EXTERN_VIS to fix __libcpp_debug_function link errors
Summary: On Windows tests that use `_LIBCPP_ASSERT` fail to link because the assertion handler function isn't correctly exported from the libc++ dylib. This patch fixes the dll import/export issues by introducing a new visibility macro `_LIBCPP_EXTERN_VIS` for use on external variables.

Reviewers: compnerd, smeenai, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D28728

llvm-svn: 292158
2017-01-16 21:01:00 +00:00
Asiri Rathnayake e3d832a3e8 [libcxx] Improve design documentation for the external-thread-library
configuration

NFC.

Differential revision: https://reviews.llvm.org/D28610

Reviewers: EricWF
llvm-svn: 292108
2017-01-16 12:44:08 +00:00
Shoaib Meenai 1b0bda3310 [libc++] Correct macro name in documenation
The macro is named `_LIBCPP_TEMPLATE_VIS`, not `_LIBCPP_TEMPLATE_ONLY`.
No functional change.

llvm-svn: 291330
2017-01-07 02:45:35 +00:00
Eric Fiselier 00f6beaed4 [libc++] Cleanup and document <__threading_support>
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.

The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist.  Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library"  with the default threading API.

Reviewers: compnerd, rmaprath

Subscribers: smeenai, cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D28316

llvm-svn: 291275
2017-01-06 20:05:40 +00:00
Eric Fiselier 011508d529 Fix Sphinx build error caused by bad indentation
llvm-svn: 291039
2017-01-05 00:04:37 +00:00
Eric Fiselier e2f2d1edef [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).

This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.

llvm-svn: 291035
2017-01-04 23:56:00 +00:00
Eric Fiselier 687d3213f0 Implement a throwing version of _LIBCPP_ASSERT.
This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:

1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
   instead of calling abort directly. Additionally this patch implements two
   handler functions, one which aborts and another that throws an exception.

2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
   contain _LIBCPP_ASSERT. This is required in order to prevent assertion
   failures throwing through a noexcept function. This macro has no effect
   unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.

Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.

Additionally this patch rewrites the documentation for debug mode.

llvm-svn: 290651
2016-12-28 04:58:52 +00:00
Shoaib Meenai dce4218df7 [libc++] Introduce `_LIBCPP_OVERRIDABLE_FUNC_VIS`
This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name
captures the semantics better, and also allows us to get rid of the
`_WIN32` check in `include/new`. No functional change.

Differential Revision: https://reviews.llvm.org/D26702

llvm-svn: 287164
2016-11-16 22:18:10 +00:00
Eric Fiselier 7ca76565e7 Fix _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to always have default visibility.
This prevent the symbols from being both externally available and hidden, which
causes them to be linked incorrectly. This is only a problem when the address
of the function is explicitly taken since it will always be inlined otherwise.

This patch fixes the issues that caused r285456 to be reverted, and can
now be reapplied.

llvm-svn: 285531
2016-10-31 02:07:23 +00:00
Shoaib Meenai 9f50fffc04 [libc++] Correct explanation of _LIBCPP_NEW_DELETE_VIS
The behavior of this macro actually needs to apply universally on
Windows and not just when using the Microsoft CRT. Update the macro
definition and documentation accordingly.

Differential Revision: https://reviews.llvm.org/D25145

llvm-svn: 284016
2016-10-12 13:48:14 +00:00
Shoaib Meenai 3888eb66b0 [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows
Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.

The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.

Differential Revision: https://reviews.llvm.org/D25042

llvm-svn: 282644
2016-09-28 22:28:51 +00:00
Shoaib Meenai 190994e435 [libc++] Fix extern template visibility for Windows
On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.

Differential Revision: https://reviews.llvm.org/D24679

llvm-svn: 281925
2016-09-19 18:29:07 +00:00
Eric Fiselier 991c354b01 Update _LIBCPP_EXCEPTION_ABI doc with @mclow's feedback
llvm-svn: 281695
2016-09-16 02:51:26 +00:00
Eric Fiselier f8f31c4985 [libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility
Summary:
GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'.  

```
// RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
// RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
#define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline))

template <class T>
struct Foo {
  void foo();
  void bar();
};

template <class T>
void Foo<T>::foo() {}

template <class T>
inline INLINE_VISIBILITY
void Foo<T>::bar() {}

template struct Foo<int>;
```

This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated). 

Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline`  therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors).

This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`.

After applying this patch GCC dylibs now contain:
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE`
  * `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl`
  * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_`
  * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl`
  * `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE`
  * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw`
  * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl`
  * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E`
  * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl`
  * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw`


This patch has no effect on Clang based builds.



Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF

Subscribers: beanz, cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D24600

llvm-svn: 281681
2016-09-16 00:00:48 +00:00
Eric Fiselier 49e2967f27 [libc++] Fix and document visibility attributes for Clang, GCC and Windows.
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!

This patch adds two new visibility macros:

* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.

After applying this patch GCC only emits one -Wattribute warning opposed to 30+.


Reviewers: mclow.lists, EricWF

Subscribers: beanz, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D24602

llvm-svn: 281673
2016-09-15 22:27:07 +00:00
Eric Fiselier 29ada6d178 Use __config_site when building libc++. Also cleanup ABI versioning doc
llvm-svn: 250261
2015-10-14 00:22:05 +00:00
Eric Fiselier b34aa900fc Fix whitespace in doc
llvm-svn: 250238
2015-10-13 22:22:42 +00:00
Eric Fiselier f9f796e79b [libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,

This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.

Please read the design documentation added in this patch for a description of how it works.

Reviewers: mclow.lists, danalbert, jroelofs, EricWF

Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits

Differential Revision: http://reviews.llvm.org/D13407

llvm-svn: 250235
2015-10-13 22:12:02 +00:00