Summary:
This is not mandated by the Standard, but it's nonetheless a nice
property to have, especially since it's so easy to implement. It
also shrinks our bug list!
PR41714
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62618
llvm-svn: 363075
Summary:
Following the discussion on the libcxx-dev mailing list
(http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html),
this implements the new policy for handling experimental features and
their deprecation. We basically add a deprecation warning for
std::experimental::filesystem, and we remove a bunch of <experimental/*>
headers that were now empty.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62428
llvm-svn: 363072
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
Some tests require `TEST_WORKAROUND_CONSTEXPR_IMPLIES_NOEXCEPT`, but they
did not include the header that defines that macro.
Thanks to Michael Park for the patch.
Differential Revision: https://reviews.llvm.org/D62920
llvm-svn: 362660
This commit adds tests that repeated characters in regular expressions
are within numeric limits, and that a <= b in a regex like `x{a,b}`.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D62816
llvm-svn: 362525
ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.
Differential Revision: https://reviews.llvm.org/D62770
llvm-svn: 362311
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.
Differential Revision: https://reviews.llvm.org/D62566
llvm-svn: 362058
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
As of r360984, LLD supports dependent libraries feature for ELF.
libunwind, libc++abi and libc++ have library dependencies: libdl librt
and libpthread, which means that when libunwind and libc++ are being
statically linked (using -static-libstdc++ flag), user has to manually
specify -ldl -lpthread which is onerous.
This change includes the lib pragma to specify the library dependencies
directly in the source that uses those libraries. This doesn't make any
difference when using linkers that don't support dependent libraries.
However, when using LLD that has dependent libraries feature, users no
longer have to manually specifying library dependencies when using
static linking, linker will pick the library automatically.
Differential Revision: https://reviews.llvm.org/D62090
llvm-svn: 362048
merged type info names.
Previously std::type_info always expected type info string to be unique.
But this isn't always the case. Like when -Bsymbolic is passed to the
linker or due to llvm.org/PR37398.
This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake
option which, when specified, overrides the default configuration for
the library.
The current defaults still assume unique names even though this isn't
strictly correct for ELF binaries. We should consider changing the
default in a follow up commit.
llvm-svn: 361913
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Reviewers: phosek, compnerd, smeenai, EricWF
Reviewed By: compnerd
Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits
Tags: #llvm, #libc
Differential Revision: https://reviews.llvm.org/D62155
llvm-svn: 361513
Some tests assume that iteration through an unordered multiset elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return
elements exactly from a set of valid values and without repetition,
but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56500
llvm-svn: 361494
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/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch is a continuation of D54838 and introduces checks verifying that
any iteration will return elements exactly from a set of valid values
and without repetition, but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56498
llvm-svn: 361414
The MSVC CRT uses TLS storage to implement per-thread locales.
This storage gets freed during program termination, and if we attempt
to do any io operations (like flushing the std streams) after this occurs
the program may abort.
This patch is a speculative fix for that issue.
The fix tries forcing the initialization of the locale TLS before
initializing the std streams. This should mean that the TLS is freed
after we destroy the streams.
llvm-svn: 361348
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
Use std::nextafter() instead of std::nexttoward() in midpoint tests.
In the context of this test, this should not cause any difference.
Since nexttowardl() is not implemented on NetBSD 8, the latter function
combined with 'long double' type caused test failure. nextafterl() does
not have this problem.
Differential Revision: https://reviews.llvm.org/D61748
llvm-svn: 360673
When builing the hermetic static library, the compiler switch
-fvisibility-global-new-delete-hidden is necessary to get the new and
delete operator definitions made correctly. However, when those
definitions are not included in the library, then this switch does harm.
With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF
symbols makes it an error to leave them undefined or defined via dynamic
linking that should generate PLTs for -shared linking (lld makes this a
hard error even without -z defs). Though leaving the symbols undefined
would usually work in practice if the linker were to allow it (and the
user didn't pass -z defs), this actually indicates a real problem that
could bite some target configurations more subtly at runtime. For
example, x86-32 ELF -fpic code generation uses hidden visibility on
declarations in the caller's scope as a signal that the call will never
be resolved to a PLT entry and so doesn't have to meet the special ABI
requirements for PLT calls (setting %ebx). Since these functions might
actually be resolved to PLT entries at link time (we don't know what the
user is linking in when the hermetic library doesn't provide all the
symbols itself), it's not safe for the compiler to treat their
declarations at call sites as having hidden visibility.
Differential Revision: https://reviews.llvm.org/D61571
llvm-svn: 360003
Drive-by:
* Fix potential race between check and update of `throw_one` in `operator new`
* Fix latent bug in `operator delete`, which shouldn't decrement `outstanding_new` when passed a null pointer
* Specifically catch the expected `bad_alloc` in `main` instead of `...`
Differential Revision: https://reviews.llvm.org/D50860
llvm-svn: 359827
Instead of manually linking against libm/librt/libpthread, we should be
linking against libSystem on Apple platforms, and only that. libm and
libpthread are symlinks to libSystem anyway.
llvm-svn: 359808
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
llvm-svn: 359806
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).
llvm-svn: 359726
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
llvm-svn: 359703
This addresses the longstanding FIXME and makes libc++ build more
similar to other runtimes.
Differential Revision: https://reviews.llvm.org/D61275
llvm-svn: 359656
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
llvm-svn: 359596
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
llvm-svn: 359571
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
llvm-svn: 359320
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.
llvm-svn: 359275
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>>);
llvm-svn: 359255
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.
llvm-svn: 359243
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.
llvm-svn: 359229
Contrary to MSVC, MinGW compilers wants the dllexport attribute on
the declaration of an explicit template instantiation, not on the
definition.
Differential Revision: https://reviews.llvm.org/D61123
llvm-svn: 359227
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
llvm-svn: 359220
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
llvm-svn: 359159
This addresses the issue introduced in D60309 which leads to linker
scripts being generated with absolute paths.
Differential Revision: https://reviews.llvm.org/D61039
llvm-svn: 359045
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
llvm-svn: 359020
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
llvm-svn: 358988
This enables the use of this script from other build systems like
GN which don't support post-build actions as well as for static
archives.
Differential Revision: https://reviews.llvm.org/D60309
llvm-svn: 358915
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
llvm-svn: 358908
This is a followup to [1] which added a new `__debug_less::operator()` overload.
[2] added `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the original
`__debug_less::operator()` between the time of writing [1] and landing it. This
change adds `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the new overload too.
[1] https://reviews.llvm.org/rL358423
[2] https://reviews.llvm.org/rL358252
Differential Revision: https://reviews.llvm.org/D60724
llvm-svn: 358725
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
llvm-svn: 358690
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.
llvm-svn: 358677
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
llvm-svn: 358671
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.
llvm-svn: 358616
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
llvm-svn: 358614
In r358591, I added a test that uses the debug database from multiple
threads and that helped us uncover the problem that was fixed in r355367.
However, the test broke the tsan CI bots, and I think the problem is the
test allocator that was used in the test (which is not thread safe).
I'm committing again without using the test allocator, and in a separate
test file.
llvm-svn: 358610
Summary:
Otherwise, we can run into problems when the program has static variables
that need to use the debug database during their deinitialization, if
the debug DB has already been deinitialized.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60830
llvm-svn: 358602
This reverts r358591, which seems to have uncovered an actual bug and
causes the tsan CI to fail. We need to fix the bug and re-commit the
test.
llvm-svn: 358593
Summary:
I'm not sure what the problem was at the time, however I don't think
this is necessary since buildit doesn't exist anymore.
Instead of the workaround, the correct thing to do is to leave out
the get_new_handler/set_new_handler definitions from libc++ when
we're getting them from libc++abi.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60717
llvm-svn: 358518
There are many STL algorithms (such as lexicographical_compare) that compare
values pointed to by iterators like so:
__comp(*it1, *it2);
When building with `_LIBCPP_DEBUG=0`, comparators are wrapped in `__debug_less`
which does some additional validation. But `__debug_less::operator()` takes
non-const references, so if the type of `*it1` is int, not int&, then the build
will fail.
This change adds a `const&` overload for `operator()` to fix the build.
Differential Revision: https://reviews.llvm.org/D60592
llvm-svn: 358423
Summary:
Otherwise, it doesn't take into account things like whether the symbol
is defined or undefined, and whether symbols are indirect references
(re-exports) or not.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60416
llvm-svn: 358408
We used to do it against the current system's libc++abi, which is not as
good as doing it with the libc++abi that matches the libc++ we're running
against.
Note that I made sure we were indeed picking up the provided libc++abi
by replacing it by something that doesn't work and watching it burn.
llvm-svn: 358294
Instead of having an `#if` block in every algorithm using a debug
comparator, this patch introduces the __comp_ref_type trait that
selects __debug_less in debug mode and _Comp& otherwise.
This patch should have no observable functionality change.
llvm-svn: 358252
Summary:
In r348529, I improved the library-defined diagnostic for using containers
with a non-const comparator/hasher. However, the check is now performed
too early, which leads to the diagnostic being emitted in cases where it
shouldn't. See PR41360 for details.
This patch moves the diagnostic to the destructor of the containers, which
means that the diagnostic will only be emitted when the container is instantiated
at a point where the comparator and the key/value are required to be complete.
We still retain better diagnostics than before r348529, because the diagnostics
are performed in the containers themselves instead of __tree and __hash_table.
As a drive-by fix, I improved the diagnostic to mention that we can't find
a _viable_ const call operator, as suggested by EricWF in PR41360.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60540
llvm-svn: 358189
In this case, CMake doesn't know about the c++abi target within the
same CMake run.
This reverts this aspect back to how it was before SVN r357811.
Differential Revision: https://reviews.llvm.org/D60448
llvm-svn: 358009
CMake already specifies those, and we never actually want those to be
used. In fact, r357811 re-ordered those flags in a way that the
explicitly-provided install_name was overriding the CMake-provided
install_name (instead of the other way around). This caused the dylib
to be considered a system dylib, and hence the explicitly provided rpath
to be ignored. This, in turn, caused some unit tests to start linking
against the system libc++.dylib instead of the freshly-built one.
Specifically, the unit tests that started linking against the system
dylib are those that didn't specify a DYLD_LIBRARY_PATH, such as
last_write_time.sh.cpp.
llvm-svn: 357946
The refactoring in r357811 made it so that we didn't add the ABI library
to the list of LIBCXX_LIBRARIES. As a result, benchmarks didn't link to
the ABI library and were missing symbols. This broke the build bots.
As a drive-by fix, we also provide the SHARED ABI library to the linker
script instead of the STATIC ABI library.
This couldn't be discovered on Apple platforms because libc++.dylib
re-exports libc++abi.dylib symbols there.
llvm-svn: 357818
Summary:
There's a lot of CMake logic that's only relevant to the shared library,
yet it was using a code path and setting variables that impact both the
shared and the static libraries. This patch moves this logic so that it
clearly only impacts the shared library.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60276
llvm-svn: 357811
We fixed incorrect behavior of input streams in r357775 and tests were
added accordingly. However, older versions of macOS don't have the
change in the dylib yet, so the tests fail on those platforms.
llvm-svn: 357794
Summary:
This is a re-application of r357533 and r357531. They had been reverted
because we thought the commits broke the LLDB data formatters, but it
turns out this was because only r357531 had been included in the CI
run.
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
This effectively implements the wording in p1264r0. It hasn't been voted
into the Standard yet, however there is wide agreement that the fix is
correct and it's just a matter of time before the fix is standardized.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357775
This builds on the work done in r342808 and adds _LIBCPP_NODISCARD_EXT
to 37 more functions, namely:
adjacent_find, all_of, any_of, binary_search, clamp, count_if, count,
equal_range, equal, find_end, find_first_not_of, find_first_of, find_if,
find, includes, is_heap_until, is_heap, is_partitioned, is_permutation,
is_sorted_until, is_sorted, lexicographical_compare, lower_bound,
max_element, max, min_element, min, minmax_element, minmax, mismatch,
none_of, remove_if, remove, search_n, search, unique, upper_bound
The motivation here is that we noticed that find_if is nodiscard with
Visual Studio's standard library, and we deemed that useful
(https://crbug.com/948122).
https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/
says "Our criteria for emitting the warning are: discarding the return
value is a guaranteed leak [...], discarding the return value is
near-guaranteed to be incorrect (e.g. remove()/remove_if()/unique()), or
the function is essentially a pure observer (e.g. vector::empty() and
std::is_sorted())." so I went through algorithm and tried to apply these
criteria.
Some of these, like vector::empty() are already nodiscard per C++
standard and didn't need changing.
I didn't (yet?) go over std::string::find* methods which should probably
have _LIBCPP_NODISCARD_EXT too (but not as part of this change).
Differential Revision: https://reviews.llvm.org/D60145
llvm-svn: 357619
Summary:
Comparing against the empty string should generate much better code that
what it does today.
We can also generate better code when comparing against literals that
are larger than the SSO space.
Reviewers: EricWF
Subscribers: christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59781
llvm-svn: 357614
Summary:
Otherwise, std::is_pointer<id __strong> works, but std::is_pointer<id __weak>
(and others) don't work as expected.
The previous patch (r357517) had to be reverted in r357569 because it
broke the Chromium build. This patch shouldn't have the same problem.
rdar://problem/49126333
Reviewers: ahatanak, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60087
llvm-svn: 357586
This addresses the issue introduced in r354212 which broke the case when
static libc++abi is merged into static libc++, but shared libc++ is
linked against shared libc++. There are 4 different possible
combinations which is difficult to capture using a single variable. This
change splits LIBCXX_CXX_ABI_LIBRARY into two:
LIBCXX_CXX_SHARED_ABI_LIBRARY and LIBCXX_CXX_STATIC_ABI_LIBRARY to
handle the shared and static cases. This in turn allows simplification
of some of the logic around merging of static archives.
Differential Revision: https://reviews.llvm.org/D60114
llvm-svn: 357556
Fixed the inability to properly rebind the testing allocator, by making the
inner alloc_impl type a plain struct and making the operations templates. Before
rebind failed to compile complaining that a alloc_impl<T>* was not convertible
to an alloc_impl<U>*.
This enables the test to pass for MSVC++ once we provide the strong guarantee
for the copy assignment operator.
Reviewed as https://reviews.llvm.org/D60023
llvm-svn: 357545
This reverts commits r357533 and r357531, which broke the LLDB
data formatters. I'll hold off until we know how to fix the data
formatters accordingly.
llvm-svn: 357536
Summary:
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
I will submit a paper in San Diego to clarify the Standard such that the
interpretation used in this commit (and other implementations) is the only
possible one.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357531
The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
were trying to construct.
llvm-svn: 357453
Summary: Completes P0357R3, which was merged into the C++20 Working Draft in San Diego.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54722
llvm-svn: 357423
Summary:
Currently the C++03 implementation of common_type has much different behavior than the C++11 one. This causes bugs, including inside `<chrono>`.
This patch unifies the two implementations as best it can. The more code they share, the less their behavior can diverge.
Reviewers: mclow.lists, ldionne, sbenza
Reviewed By: mclow.lists, ldionne
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59678
llvm-svn: 357370
Some tests #include <iostream> but they don't use anything from the
header. Those are probably artifacts of when the tests were developped.
llvm-svn: 357181
The old implementation assumed the POSIX `setlocale()` API where the old
locale is returned. On Windows, the _new_ locale is returned. This meant
that `__libcpp_locale_guard` wasn't resetting the locale on destruction.
The new implementation fixes the above issue and takes advantage of
`setlocale(LC_ALL)` to reduce the number of calls, and also avoids setting
the locale at all if it's not necessary.
Differential Revision: https://reviews.llvm.org/D59572
llvm-svn: 357104
Dylib support for shared_mutex was added in macOS 10.12, so the tests
should be XFAILed accordingly instead of being completely disabled
whenever availability is enabled.
rdar://problem/48769104
llvm-svn: 357079
When the output buffer is too small to contain the output, `vsnprintf()`
fills the buffer and returns the number of characters that __would have__
been written if the buffer was sufficiently large.
`_vnsprintf_s()` on the other hand fills the buffer and returns -1 when this
happens. We want the former behavior, but we also want to be able to
pass in a locale to prevent having to call `setlocale()`.
`__stdio_common_vsprintf()` is the only function general enough to get
the behavior we want.
Differential Revision: https://reviews.llvm.org/D59727
llvm-svn: 357024
Summary:
Adds the coroutine `std::experimental::task<T>` type described in proposal P1056R0.
See https://wg21.link/P1056R0.
This implementation allows customization of the allocator used to allocate the
coroutine frame by passing std::allocator_arg as the first argument, followed by
the allocator to use.
This supports co_awaiting the same task multiple times. The second and
subsequent times it returns a reference to the already-computed value.
This diff also adds some implementations of other utilities that have potential for
standardization as helpers within the test/... area:
- `sync_wait(awaitable)` - See P1171R0
- `manual_reset_event`
Move the definition of the __aligned_allocation_size helper function
from <experimental/memory_resource> to <experimental/__memory>
so it can be more widely used without pulling in memory_resource.
Outstanding work:
- Use C++14 keywords directly rather than macro versions
eg. use `noexcept` instead of `_NOEXCEPT`).
- Add support for overaligned coroutine frames.
This may need wording in the Coroutines TS to support passing the extra `std::align_val_t`.
- Eliminate use of `if constexpr` if we want it to compile under C++14.
Patch by @lewissbaker (Lewis Baker).
llvm-svn: 357010
Summary:
I can't see a good reason to disallow this, even though it isn't the
standard way we build libc++ for Apple platforms.
Making this work on Apple platforms requires using different flags for
--whole-archive and removing the -D flag when running `ar` to merge
archives because that flag isn't supported by the `ar` shipped on Apple
platforms. This shouldn't be an issue since the -D option appears to be
enabled by default in GNU `ar`.
Reviewers: phosek, EricWF, serge-sans-paille
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59513
llvm-svn: 356903
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
I don't understand why we don't always do that. We do it for normal `if`s
in the code, but not for preprocessor `if`s? It's a lot more readable when
indented properly.
llvm-svn: 356693
This documentation was removed when we added <filesystem> to the dylib
in r356518, but it really should have been updated to reflect the new
state of things. Keeping documentation around doesn't hurt and users
will have an easier time migrating.
llvm-svn: 356681
Summary:
Add relational benchmark against a string constant.
These can potentially trigger inlining of the operations. We want to
benchmark that.
Reviewers: EricWF
Subscribers: christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59512
llvm-svn: 356680
_LIBCPP_TYPE_VIS is only really needed on types with a vtable.
And on Windows it doesn't work with types that have only inline methods.
This patch removes the unneeded attributes.
llvm-svn: 356637
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
`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't.
Windows is LLP64, which means unsigned long is 32-bit even on 64-bit
systems.
pplwin.h contains
static_assert(alignof(void *) == alignof(::std::once_flag), ...)
which fails due to this problem.
Instead of unsigned long, use uintptr_t, which consistently is 32-bit
on 32-bit systems and 64-bit on 64-bit systems.
No functional change except on 64-bit Windows.
Differential Revision: https://reviews.llvm.org/D59607
llvm-svn: 356624
Summary:
Also add the corresponding XFAILs to tests that require filesystem.
The approach taken to mark <filesystem> as unavailable in this patch
is to mark all the header as unavailable using #pragma clang attribute.
Marking each declaration using the attribute is more intrusive and
does not provide a lot of value right now because pretty much everything
in <filesystem> requires dylib support, often transitively.
This is an alternative to https://reviews.llvm.org/D59093.
A similar (but partial) patch was already applied in r356558.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59224
llvm-svn: 356616
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
This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.
This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.
llvm-svn: 356558
This silences a known issue, as can be seen by looking at similar
tests for other clocks, like time.clock.steady/consistency.pass.cpp.
llvm-svn: 356528
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:
Otherwise, implicit instantiations of templates with these types can
cause the dylib to start exporting the vtable/RTTI of the instantiation.
Giving hidden visibility to those types causes the compiler to understand
that they are not used outside the dylib, and as a result implicitly
instantiated vtables/RTTI of templates with those internal types will
get hidden visibility.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59550
llvm-svn: 356488
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
Even though the header makes the exact same check since https://llvm.org/D59063,
the headers could conceivably change in the future and introduce a bug.
llvm-svn: 356376
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
Summary:
In r342843, I added deprecation warnings to some facilities that were
deprectated in C++14 and C++17. However, those deprecation warnings
were not enabled by default.
After discussing this on IRC, we had finally gotten consensus to enable
those warnings by default, and I'm getting around to doing that only
now.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58140
llvm-svn: 355961
When Clang tries to complete a type containing `std::optional` it
considers the `in_place_t` constructor with no arguments which checks
if the value type is default constructible. If the value type is a
nested class type, then this check occurs too early and poisons the
is_default_constructible trait.
This patch makes optional deduce `in_place_t` so we can prevent
this early SFINAE evaluation. Technically this could break people
doing weird things with the in_place_t tag, but that seems less
important than making the nested class case work.
llvm-svn: 355877
Summary:
I can't think of a reason for shipping this empty header. If there is
a reason to do so, then hopefully this review can uncover it.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59137
llvm-svn: 355829
Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344
new_delete_resource().allocate(n, a) has basically two permissible results:
* Return an appropriately sized and aligned block.
* Throw bad_alloc.
Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was
to return an appropriately sized but inappropriately under-aligned block. This is now fixed.
(This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't
trust the default resource to return appropriately aligned blocks, pretty much everything breaks.
For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't
care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.)
llvm-svn: 355763
When dllimport is specified on a class, and
exclude_from_explicit_instatiation is specified on a member, clang-cl
will still expect a definition to be available externally. But this is
not correct.
Surprisingly one one symbol seems to be consistently affected by this
bug. So this patch simply works around it there.
llvm-svn: 355760
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:
We need to pin the underlying type of C++20' `std::memory_order` to match the C++17 version. Anything less is an ABI break.
At the moment it's `unsigned` before C++20 and `int` after. Or if you're using `-fshort-enums` it's `unsigned char` before C++20 and `int` after.
This patch explicitly specifies the underlying type of the C++20 `memory_order` to be w/e type the compiler would have chosen for the C++17 version.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: jfb, jdoerfert, #libc, zoecarver
Differential Revision: https://reviews.llvm.org/D59063
llvm-svn: 355755
comparator for std::sort()
Our debug comparator assumed that the comparator it wraps would always
accepts the values by const ref. This isn't required by the standard.
This patch makes our __debug_less comparator forward the constness.
llvm-svn: 355752
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
The issue is the following code:
__cn1->__add(*__ip);
(*__ip)->__c_ = __cn1;
`__ip` points into the array of iterators for container `__cn2`. This code adds
the iterator to the array of iterators for `__cn1`, and updates the iterator to
point to the new container.
This code works fine, except when `__cn1` and `__cn2` are the same container.
`__cn1->__add()` might need to grow the array of iterators, and when it does,
`__ip` becomes invalid, so the second line becomes a use-after-free error.
Simply swapping the order of the above two lines is not sufficient, because of
the memmove() below. The easiest and most performant solution is just to skip
touching any iterators if the containers are the same.
Differential Revision: https://reviews.llvm.org/D58926
llvm-svn: 355550
Summary:
Currently, libc++'s `<stdexcept>` doesn't play nice with `vcruntime`. Specifically:
* `logic_error` and `runtime_error` have a different layout.
* libc++'s `logic_error` and `runtime_error` override `what()` but `vcruntime` does not.
* `vcruntime` uses weak vtables for `<stdexcept>` types.
* libc++'s `<stdexcept>` constructors and assignment operators may have different manglings than `vcruntimes`.
This patch makes libc++'s declarations in `<stdexcept>` match those provided by MSVC's STL as closely as possible.
If MSVC doesn't declare a special member, then neither do we. This ensures that the implicit definitions have the same linkage, visibility, triviality, and noexcept-ness.
Reviewers: thomasanderson, ldionne, smeenai
Reviewed By: thomasanderson
Subscribers: jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58945
llvm-svn: 355546
Summary:
This breaks ABI for folks using -fshort-enums, and does not really buy
us anything.
http://llvm.org/PR40977
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Differential Revision: https://reviews.llvm.org/D59029
llvm-svn: 355521
Otherwise, when testing trunk libc++ on an older system, lit will think
that the dylib features are disabled. Ideally, we'd have a notion of
running the tests with/without a deployment target (or, equivalently,
a deployment target representing trunk where everything is as recent
as can be). Since we always have a deployment target right now (which
defaults to the current system), we only enable those features when
we're going to also be testing with the system libc++.
We also need to disable the availability markup when we are not running
a system library flavor, because availability markup does not make sense
when building against the trunk libc++ (which has everything regardless
of what the current system is).
This is a re-application of r353319, which had been reverted due to
CI breakage. This time around, I made sure it didn't break our internal
CI before submitting.
This is also a partial undoing of r348296, in spirit at least. However,
with this patch, availability markup is enabled based on whether we're
using a system library or not, whereas previously one could enable
it or disable it arbitrarily. This was confusing as it led to testing
configurations that don't make sense (such as testing a system library
without availability markup, or trunk testing with availability markup).
llvm-svn: 355451
Marshall Clow