This change introduces support for building libc++. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D61143
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359806 91177308-0d34-0410-b5e6-96231b3b80d8
Linux is failing even though the test runner does report this locale
is available, but the test still isn't expected to work on platforms
without the locale (like Android).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359726 91177308-0d34-0410-b5e6-96231b3b80d8
This adds explicit support for the WASI platform to libcxx.
WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.
Differential Revision: https://reviews.llvm.org/D61336
Reviewers: sbc100, ldionne
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359703 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests.
This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed.
Reviewers: rsmith, ldionne, dlj, mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D61301
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359596 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of populating the global LIBCXX_LIBRARIES, we use the link-time
dependency management built into CMake to propagate link flags. This
leads to a cleaner and easier-to-follow build.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60969
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359571 91177308-0d34-0410-b5e6-96231b3b80d8
The standard requires the following for the std::regex_constants::error_type
values: "The type error_type is an implementation-defined enumerated type."
The values of this enumerated type are not required to be non-zero.
This patch makes such checks in tests libc++-specific to let the tests
pass for other conforming implementations.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D61195
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359320 91177308-0d34-0410-b5e6-96231b3b80d8
When r359229 added noexcept to the declaration of `~mutex`, it didn't
add it to the definition which caused -Wimplicit-exception-spec-mismatch
to fire. This just adapts the definition to agree with the declaration.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359275 91177308-0d34-0410-b5e6-96231b3b80d8
When the arguments to tuple cat were const, the const was incorrectly
propagated into the type of the resulting tuple. For example:
const std::tuple<int> t(42);
auto r = std::tuple_cat(t, t);
// Incorrect! should be std::tuple<int, int>.
static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>);
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359255 91177308-0d34-0410-b5e6-96231b3b80d8
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t)
valarray<size_t>::~valarray()
valarray<size_t>::resize(size_t, size_t)
The first two of these are intended to be removed in V2 of the ABI: they're
attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention
is that these symbols from the library are not used even when building using
the V1 ABI. However, there are explicit instantiation declarations for all
three symbols in the header, which are not correct as we do not intend to find
an instantiation of these functions that is provided elsewhere.
(A recent change to clang to properly diagnose explicit instantiation
declarations of internal linkage functions -- required by [temp.explicit]p13 --
had to be rolled back because it diagnosed these explicit instantiations.)
Remove the explicit instantiation declarations, and remove the explicit
instantiation definitions for V2 of the libc++ ABI onwards.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359243 91177308-0d34-0410-b5e6-96231b3b80d8
std::mutex was not actually is_nothrow_default_constructible in C++98/C++03,
because the variable declaration
std::mutex M;
... could throw an exception from the mutex destructor. Fix it by marking the
destructor as non-throwing. This has no effect in C++11 onwards, because
destructors are non-throwing by default in those language modes.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359229 91177308-0d34-0410-b5e6-96231b3b80d8
All constant expressions are non-potentially-throwing in C++14, but that is *not* the case in C++17. Change these tests of the `variant`-flavored overloads of `std::get` to expect the correct behavior when the compiler is not GCC or is GCC 9+.
Credit to Jonathan Wakely for providing an improved version of my initial change that validates the incorrect behavior on GCC < 9 as well as validating the correct behavior on other compilers.
Differential Revision: https://reviews.llvm.org/D61033
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359220 91177308-0d34-0410-b5e6-96231b3b80d8
Teach libcxx to stop using various deprecated __has_* type traits, in favor of
the ("modern", C++11 era) __is_* type traits.
This is mostly just a simplification, but fixes at least one bug: _Atomic T
should be considered trivially-destructible, but is not considered to be POD by
Clang, and __has_trivial_destructor is specified in the GCC documentation as
returning false for non-POD non-class types.
Differential Revision: https://reviews.llvm.org/D48292
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359159 91177308-0d34-0410-b5e6-96231b3b80d8
Clang recently added __builtin_is_constant_evaluated() and GCC 9.0
has it as well.
This patch adds support for it in libc++.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359119 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers.
This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.
Suggestions for a cleaner implementation are welcome.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60097
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359020 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In a bunch of places, we used to check whether LIBCXX_BUILDING_LIBCXXABI
is defined OR we're building for an Apple platform. This used to
be necessary in a time when Apple's build script did NOT define
LIBCXX_BUILDING_LIBCXXABI. However this is not relevant anymore
since Apple's build does define LIBCXX_BUILDING_LIBCXXABI.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60842
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358988 91177308-0d34-0410-b5e6-96231b3b80d8
Due to MSVC's decision to encode `wchar_t` as UTF-16, it rejects wide
character/string literals that expect a character value greater than
`\xffff`. UTF-16 `wchar_t` is clearly non-conforming, given that the
standard requires wchar_t to be capable of representing all characters
in the supported wide character execution sets, but rejecting e.g.
`\x40003` is a reasonably sane compromise given that encoding choice:
there's an expectation that `\xFOO` produces a single character in the
resulting literal. Consequently `L'\x40003'`/`L"\x40003"` are ill-formed
literals on MSVC. `L'\U00040003'` is a high surrogate (and produces a
warning about ignoring the "second character" in a multi-character
literal), and `L"\U00040003"` is a perfectly-valid `const wchar_t[3]`.
This change updates these tests to use universal-character-names instead
of raw values for the intended character values, which technically makes
them portable even to implementations that don't use a unicode
transformation format encoding for their wide character execution
character set. The two-character literal `L"\u1005e"` is awkward - the
`e` looks like part of the UCN's hex encoding - but necessary to compile
in '03 mode since '03 didn't allow UCNs to be used for members of the
basic execution character set even in character/string literals.
I've also eliminated the extraneous `\x00` "bonus null-terminator" in
some of the string literals which doesn't affect the tested behavior.
I'm sorry about using `*L"\U00040003"` in `conversions.string/to_bytes.pass.cpp`,
but it's correct for platforms with 32-bit wchar_t, *and* doesn't
trigger narrowing warnings as did the prior `CharT(0x40003)`.
Differential Revision: https://reviews.llvm.org/D60950
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358908 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Ensure we re-export __cxa_throw_bad_array_new_length and
__cxa_uncaught_exceptions from libc++, since they are now
provided by libc++abi.
Doing this allows us to stop linking explicitly against libc++abi in
the libc++abi tests, since libc++ re-exports all the necessary symbols.
However, there is one caveat to that. We don't want libc++ to re-export
__cxa_uncaught_exception (the singular form), since it's only provided
for backwards compatibility. Hence, for the single test where we check
this backwards compatibility, we explicitly link against libc++abi.
PR27405
PR22654
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60424
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358690 91177308-0d34-0410-b5e6-96231b3b80d8
This used to be guarded on whether the deployment target was greater
than macosx10.8, however testing against the dylibs for 10.8 and earlier
with the function enabled works too. The revision that introduced
__pad_and_output is r164241 and it does not mention a reason for the
guard.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358677 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Let's not try to be clever and detect it based on the libc++abi setting.
The only build that puts new/delete in libc++abi is Apple's and we set
this CMake option explicitly in both libc++ and libc++abi. Complicated
dependent options hurt, let's avoid them when possible.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60797
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358671 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that whether the new handlers should be provided is orthogonal
to whether new/delete are provided in libc++ or libc++abi. The reason why
I initially added this conditional is because of an incorrect understanding
of the path we're taking when building on Apple platforms. In fact, we
always build libc++ on top of libc++abi on Apple platforms, so we take
the branch for `LIBCXX_BUILDING_LIBCXXABI` there.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358616 91177308-0d34-0410-b5e6-96231b3b80d8
Some linker libraries are only needed for shared libc++, some only
for static libc++, combining these together in LIBCXX_LIBRARIES and
LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies.
This changes splits those up into LIBCXX_SHARED_LIBRARIES and
LIBCXX_STATIC_LIBRARIES matching what libc++abi already does.
Differential Revision: https://reviews.llvm.org/D57872
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358614 91177308-0d34-0410-b5e6-96231b3b80d8
