Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.
The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.
Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52662
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@345260 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339874 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after ABI v1, which is currently the only stable ABI.
This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be
`_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only
exported by the library for historical reasons are not exported anymore
in the unstable ABI.
Because of that, this commit is an ABI break for ABI v2. This ABI version
is not stable, however, so this should not be a problem.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49914
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339012 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338122 91177308-0d34-0410-b5e6-96231b3b80d8
In upcoming changes to filesystem I plan to change file_time_type
to use __int128_t as its underlying representation, in order
to allow it to have a range and resolution at least that of
the timespec struct.
There was some pushback against this decision, so I drafted
a document explaining the problems, potential solutions, and
the rational for the decision.
However, it's probably easier to let people read the generated
HTML rather than the raw restructured text. For this reason
I'm commiting the design documents before hand, so they can
be available during any subsequent discussion or code review.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337880 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336866 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336382 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336369 91177308-0d34-0410-b5e6-96231b3b80d8
This allows keeping libcxx using win32 threads even if a
version of pthread.h is installed.
This matches the existing cmake option LIBCXX_HAS_PTHREAD_API.
Also add missing documentation about the internal define
_LIBCPP_HAS_THREAD_API_WIN32.
Differential Revision: https://reviews.llvm.org/D41764
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@321896 91177308-0d34-0410-b5e6-96231b3b80d8
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.
This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.
Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307966 91177308-0d34-0410-b5e6-96231b3b80d8
It's supposed to be "class template" and "function template" instead of
"template class" and "template function".
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307954 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302172 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296732 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@296731 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@292158 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291275 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291035 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290651 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@287164 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@285531 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@282644 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281925 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@281673 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@250235 91177308-0d34-0410-b5e6-96231b3b80d8
