When libc++ does not provide new/delete, libc++abi now also provides the
aligned allocation and deallocation functions, so those should be part of
the re-export list for libc++.
llvm-svn: 356804
Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59619
llvm-svn: 356633
Summary:
This change allows specifying the version of libc++abi's ABI to re-export
when configuring CMake. It also clearly identifies which ABI version of
libc++abi each export file contains.
Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS,
since that knowledge is not relevant anymore. Indeed, libc++ can't be
built with the toolchain that came with the 10.9 SDK anyway because
the version of Clang it includes is too old (for example if you want
to build a working libc++.dylib, you need bugfixes to visibility
attributes that are only in recent Clangs).
Reviewers: dexonsmith, EricWF
Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59489
llvm-svn: 356587
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Unlike the previous attempt (r356500), this doesn't remove all the
filesystem tests.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356518
When I applied r356500 (https://reviews.llvm.org/D59152), I somehow
deleted all of filesystem's tests. I will revert r356500 and re-apply
it properly.
llvm-svn: 356505
Summary:
This patch treats <filesystem> as a first-class citizen of the dylib,
like all other sub-libraries (e.g. <chrono>). As such, it also removes
all special handling for installing the filesystem library separately
or disabling part of the test suite from the lit command line.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59152
llvm-svn: 356500
Summary:
The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically,
I thought that if a debug violation aborted, we could only test one violation per file. This made
it impossible to test debug mode. Which throwing behavior we could test more!
However, the throwing approach didn't work either, since there are debug violations underneath noexcept
functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug
mode was off.
Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was
viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst
changing the behavior of their program.
This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style
death tests.
Reviewers: mclow.lists, ldionne, thomasanderson
Reviewed By: ldionne
Subscribers: christof, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D59166
llvm-svn: 356417
CMake will define -Dcxx_shared_EXPORTS when building the shared library
by default. In theory, this is used to signal to the library that we're
building a shared library and that dllimport/dllexport should be used.
However, we already have our own way of doing that, so I'm removing this
define to avoid meaningless command line arguments in the build.
llvm-svn: 356167
Summary:
In r355746, we stopped forcing to build with -fPIC because that should
be specified by the CMAKE_POSITION_INDEPENDENT_CODE option at CMake
configure time (and by default -fPIC is used for shared libraries anyways).
However, r355746 had to be reverted in r355756 because we were not
actually building the shared library with -fPIC. The reason is that
we were sharing an object library between the static and the shared
library, which caused flags for static libraries to be used when
building object files that were going to be used for a shared library.
Since this was resolved by r356150, we can stop forcing -fPIC again.
Reviewers: EricWF, smeenai
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59250
llvm-svn: 356153
Summary:
The problem with using an object library for doing this is that it prevents
the shared library and the static library from being built with the right
default flags. For example, CMake will build shared libraries with -fPIC
by default, but not static libraries. Using an object library to create
the shared library will prevent the right default flags for shared
libraries from being used.
As a side effect, this patch also localizes the logic related to building
a hermetic static library to the static library case, making clear that
this has no effect on the shared library.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59248
llvm-svn: 356150
This reverts commit r355764.
CMake does not turn -fPIC on for us by default. so this patch breaks
standalone builds. The only reason it hasn't broken any bots is because
LLVM turns on and specifies '-fPIC' for us.
llvm-svn: 355756
Summary:
Whether we build with -fPIC should be specified by the
CMAKE_POSITION_INDEPENDENT_CODE option at configure time.
Note that this patch doesn't change the behavior when building
by default, since -fPIC is used for shared libraries by default.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59146
llvm-svn: 355746
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
Summary:
This patch fixes a lifetime bug when inserting a new container into the debug database. It is
diagnosed by UBSAN when debug mode is enabled. This patch corrects how nodes are constructed
during insertion.
The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI
stability from debug mode.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mclow.lists, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D58011
llvm-svn: 355367
Different versions of python print dictionaries in different orders.
This can mess up diffs when updating ABI lists. This patch uses
pprint.pformat to print the dicts to get a consistent ordering.
llvm-svn: 353634
The itoa symbols were added and their addition is documented in the CHANGELOG.
I'm not sure why the valarray symbols were missing previously, but they're
present in the v1 ABI lists and should be here as well.
llvm-svn: 353633
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352688
When linking library dependencies, we shouldn't need to export linked
libraries to dependents. We should be explicit about this in
target_link_libraries, otherwise other targets that depend on these such
as sanitizers get repeated (and possibly even conflicting) dependencies.
Differential Revision: https://reviews.llvm.org/D57456
llvm-svn: 352654
This is useful when static libc++ library is being linked into
shared libraries that may be used in combination with libraries.
We want to avoid we exporting libc++ symbols in those cases where
this option is useful. This is provided as a CMake option and can
be enabled by libc++ vendors as needed.
Differential Revision: https://reviews.llvm.org/D55404
llvm-svn: 350489
Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.
Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF
Subscribers: christof, jkorous, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54804
llvm-svn: 347903
Summary:
When the Xcode Command Line tools are not installed but CMAKE_OSX_SYSROOT is
set, we would try to re-export symbols from the libc++abi.dylib shipped in
the sysroot, which does not exist. This commit changes the build on OS X to
always re-export symbols from the explicit re-export lists, which doesn't
change depending on what system you're building on, and is therefore much
less flaky.
Reviewers: EricWF, mclow.lists
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54595
llvm-svn: 347708
Summary:
This commit marks a few functions as hidden and removes them from the ABI list
on Linux such that libc++ can be built with -fvisibility=hidden. The functions
marked as hidden by this patch were exported from the shared object only
because they were implicitly instantiated function templates. It is safe
to stop exporting those symbols from the shared object because nobody could
actually depend on them: implicit instantiations are not taken from shared
objects.
The symbols removed in this commit are basically the same that had been
removed in https://reviews.llvm.org/D53868, but that patch had to be reverted
because it broke the build (because the functions were not marked as hidden
like this patch does).
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54639
llvm-svn: 347395
Summary:
This change changes the build to use -fvisibility=hidden
The exports this patch removes are symbols that should have never been exported
by the dylib in the first place, and should all be symbols which the linker
won't de-duplicate across SO boundaries, making them safe to remove.
After this change, we should be able to apply `_LIBCPP_HIDDEN` to the versioning namespace without changing the export lists.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: smeenai, mgorny, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53868
llvm-svn: 345664
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
llvm-svn: 345260
libc++ has dropped support for Mac OS 10.6 for a while, and we don't
have any testers set up for that OS.
This commit puts in an error message so that people can reach out to
the libc++ maintainers in case support for 10.6 is still expected (as
opposed to silently failing in weird ways). We can completely drop
support for 10.6 and remove the error message some time in the future
when we're sure that nobody is relying on it.
llvm-svn: 344576
Summary:
r342805 added support for the check-cxx-abilist target on FreeBSD, but broke
the target on macOS in doing so. The problem is that the GENERIC_TARGET_TRIPLE
gets overwritten after replacing the FreeBSD regular expression, which
nullifies the replacement done with the darwin regular expression.
Reviewers: dim, EricWF
Subscribers: emaste, mgorny, krytarowski, christof, dexonsmith, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52394
llvm-svn: 342813
Summary:
They are introduced in r338479; their Linux ABI changes are recorded in r338486.
TODO: Record the Mac OS X ABI changes.
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: christof, ldionne, libcxx-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D52391
llvm-svn: 342810
numbers off of freebsd target triples, when generating the name of the
ABI list file for check-cxx-abilist target.
Also remove unnecessary parentheses in the regex for darwin, and
slightly reword the comment.
llvm-svn: 342805
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
llvm-svn: 339012
The bots were failing to build the cxx_filesystem target, so the
tests were failing. Though this does lead me to wonder how it
was ever working with c++experimental.
llvm-svn: 338095
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
Louis Dionne