This patch add the target-* (x86_64-*) as used elsewhere in llvm.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D88027
The explicit call to `std::setlocale(LC_ALL, "C")` isn't required, since
the Standard already says the equivalent of this call is performed on
program startup.
On windows, wchar_t is 16 bit, while we might be widening chars to
char32_t.
This cast had been present since the initial commit, and removing it
doesn't seem to make any tests fail.
Differential Revision: https://reviews.llvm.org/D90228
On windows, the previous path replacement using forward slashes wouldn't
work, and so we'd end up including the same file again. We would do that
until we'd hit the recursion limit of the Python interpreter.
Instead, use `os.path` to properly replace without assuming a specific
path separator.
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
The variable declarations interleaved with logic was really difficult
to read. Instead, simply have two different implementations for _WIN32
and others.
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib. However, we don't
support back-deploying to such old deployment targets anymore, so the
workaround can be dropped.
Now libc++ pipeline will be triggered from the "premerge-checks" and the
combined result are going to be returned to Harbormaster.
Reviewed-by: ldionne
Differential Revision: https://reviews.llvm.org/D89113
The individual enum values in copy_options and file_type aren't
specified in the standard.
The standard doesn't require fs::path::format to be a scoped enum.
Differential Revision: https://reviews.llvm.org/D89866
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
Split the resolution check to a separate test, which is marked as
unsupported on windows.
On windows (both with MS STL and libstdc++), the file time has
100 ns resolution; the standard doesn't mandate a specific resolution.
Differential Revision: https://reviews.llvm.org/D89535
Use p.string() instead of p.native() for comparing with the expected
value.
Explicitly list the expected values for both posix and windos, even if
the operation is an identity operation on posix.
Differential Revision: https://reviews.llvm.org/D89532
This is defined both by libcxx/utils/libcxx/test/config.py (for
any windows target) and msvc_stdlib_force_include.h (when testing
specifically the MSVC C++ library).
The command line define (-D_CRT_SECURE_NO_WARNINGS) defines it to the
value 1; change the header define to match that.
Keeping both instances, to keep the fix for cases when not building
in cases that don't use config.py.
Also remove a comment about whether this can be removed; it can't at
least be removed altogether - doing that breaks a number of tests that
otherwise succeed.
Differential Revision: https://reviews.llvm.org/D89588
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
Use `__FUNCSIG__` instead when compiling with MSVC. While we're touching `makeTypeIDImp`, remove the warning suppression for C4640 "construction of local static object is not thread safe" since C1XX now correctly constant-initializes `id`.
The Standard doesn't include the
```c++
template<class T>
T* atomic_fetch_meow(atomic<T*>, ...);
```
templates these tests are testing.
(See https://bugs.llvm.org/show_bug.cgi?id=47908)
Use fs::path as variable type instead of std::string, when the input
potentially is a path, as they can't be implicitly converted back to
string.
Differential Revision: https://reviews.llvm.org/D89674
Use .string() instead of .native() in places where we want to combine
paths with std::string.
Convert some methods to take a fs::path as parameter instead of
std::string, for cases where they are called with paths as
parameters (which can't be implicitly converted to std::string if
the path's string_type is wstring).
Differential Revision: https://reviews.llvm.org/D89530
Mark this as a libcpp specific test; the standard doesn't say that
this method should be noexcept.
Differential Revision: https://reviews.llvm.org/D89677
The standard doesn't declare this overload as noexcept, but doesn't
either say that it strictly cannot be noexcept either. The function
doesn't throw on errors that are signaled via error_code, but the
standard says that it may throw a bad_alloc.
This fixes an error with libstdc++ on linux.
Differential Revision: https://reviews.llvm.org/D89678
This makes them more readable in llvm-lit's output on failures.
This only applies the change on the filesystem test subdir.
Differential Revision: https://reviews.llvm.org/D89680
It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accepts -std=c++2a is 5,
so mark these as UNSUPPORTED for clang-5 to clang-9.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D89704
Define all the fuzzing tests in libcxx/test/libcxx/fuzzing, and get
rid of the ad-hoc libcxx/fuzzing directory, which wasn't properly
integrated with the build system or test suite.
As a fly-by change, this also reduces the dependencies of fuzzing tests
on large library components like <iostream>, to make them work on more
platforms.
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
This changes the checking for available locales to use one program that
iterates over argv to test multiple locale names instead of checking each
name with a separate executable.
This massively speeds up running individual tests using an SSH executor
(it can take up to 10 seconds to compile and run a single test in some
emulated environments) in case no locales are installed since then all
fallback names are tested idividually. But even on a native machine
this reduces the libc++ lit startup time by ~1-2 second for me on a machine
that does not have locale data installed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88884
On FreeBSD we get the following error when passing zero as the requested
alignment: error: requested alignment is not a power of 2
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88820
Use string() for convenience for testing where possible, but keep using
native() for move tests where we want to check that no allocations are
made, constructing a reference fs::path::string_type instead.
Use the right value_type in a few places.
Make the synop test check for the right types and for the expected
preferred separator.
Differential Revision: https://reviews.llvm.org/D89537
Instead of having this script be part of the OSS-Fuzz repository, I think
it makes more sense to have it alongside the rest of the fuzzing targets
in libc++.
This fixes building with libstdc++ for windows. MS STL has got
ifstream/ofstream overloads that taken wide strings though.
Differential Revision: https://reviews.llvm.org/D89539
rGcc69d211d0d65d7b introduced several uses of `printf` with format
directives `%lu` and `%ld` to format values of type `size_t` and
`ptrdiff_t` respectively.
That doesn't reliably work in all C implementations, because those
types aren't necessarily the same thing as 'long int': sometimes
they're not even the same size, and when they are the same size, they
might be officially defined as int rather than long (for example),
which causes clang to emit a diagnostic for the mismatch.
C has special-purpose printf modifier letters for these two types, so
it's safer to use them. Changed all `%lu` on `size_t` to `%zu`, and
all `%ld` on `ptrdiff_t` to `%td`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D89545
We included <istream> and <ostream> from <random>, but really it is
sufficient to include <iosfwd> if we make sure we access ios_base
members through a dependent type. This allows us to break a hard
dependency of <random> on locales.
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
Also, some tests had multiple death tests in them, so split them into
separate tests instead. The second death test would obviously never
get run, because the first one would kill the program before.
While this adds some convenience to the test suite, it prevents the tests
using these checkpoints from being used on systems where signals are not
available, such as some embedded systems. It will also prevent these tests
from being constexpr-friendly once e.g. std::map is made constexpr, due
to the use of statics.
Instead, one can always use a debugger to figure out exactly where a
test is failing when that isn't clear from the log output without
checkpoints.
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
This simplifies the workflow for adding new feature-test macros for
contributors. Previously, they would have to move the generated <version>
header from a temporary directory to libc++'s include directory by hand.
This makes the behavior for the <version> header consistent with what's
done for the tests and the documentation.
To make it clearer this is about whether the library supports the debug
mode at all, not whether the debug mode is enabled. Per comment by Nico
Weber on IRC.
Due to the need to support compilers that implement builtin operator
new/delete but not their align_val_t overloaded versions, there was a
lot of complexity. By assuming that a compiler that supports the builtin
new/delete operators also supports their align_val_t overloads, the code
can be simplified quite a bit.
Differential Revision: https://reviews.llvm.org/D88301
We don't support any compiler that doesn't support variadics and rvalue
references in C++03 mode, so these workarounds can be dropped. There's
still *a lot* of cruft related to these workarounds, but I try to tackle
a bit of it here and there.
To make sure we don't store a mutable object (which could be modified by
outside code without us noticing) as the cache key, we pickle the cache
key to get a byte stream. If two keys are unequal, we know for sure they
will not have the same pickling. And if they are equal, there's a large
chance they will have the same pickling. If they don't, we might end up
not reusing a cached entry when we could have, but at least the behavior
we'll have is semantically correct.
This significantly speeds up the configuration of libc++'s test suite
by making sure that we don't perform the same operations over and over
again.
Differential Revision: https://reviews.llvm.org/D89003
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable. This is a follow up to D56702 which addressed
one instance, this patch addresses all of the remaining ones.
Differential Revision: https://reviews.llvm.org/D88188
This is a cherrypick of the upstream fix commit ffe1342 onto
`llvm/utils/benchmark` and `libcxx/utils/google-benchmark`.
This adds CycleTimer implementation for M680x0, which simply
uses `gettimeofday` same as MIPS.
Differential Review: https://reviews.llvm.org/D88868
Some libc++ builds may want to disable support for the debug mode,
for example to reduce code size or because the current implementation
of the debug mode requires a global map. This commit adds the
LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test
suite.
It also adds a CI job to test this configuration going forward.
Differential Revision: https://reviews.llvm.org/D88923
__clear_and_shrink() was added in D41976, and a test was added alongside
it to make sure that the string invariants were maintained. However, it
appears that the test never ran under UBSan before, which would have
highlighted the fact that it doesn't actually maintain the string
invariants.
Differential Revision: https://reviews.llvm.org/D88849
The clock_gettime function is available when _POSIX_TIMERS is defined.
We check for this and set _LIBCPP_USE_CLOCK_GETTIME accordingly since
59b3102739. But check for _LIBCPP_USE_CLOCK_GETTIME was removed in
babd3aefc9. As a result, code is now trying to use clock_gettime even
on platforms where it is not available and it is causing build failure
with newlib.
This patch restores the checks to fix this.
Differential Revision: https://reviews.llvm.org/D88825
In our CHERI Jenkins CI we need to pass `-F <custom_config_file>` to each
ssh/scp command to set various arguments such as the localhost port, usage
of controlmaster, etc. to speed up connections to our emulated QEMU systems.
For our specific use-case I could have also added a single --ssh-config-file
argument that can be used for both the scp and ssh commands, but being able
to pass arbitrary extra flags for both commands seems more flexible.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D84097
This is flagged by PyCharm and can cause subtle bugs. While changing this
also re-sort the imports and add missing ones.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88816
We might end up including more headers than strictly necessary this way,
but it's much simpler and it makes it easier to port thread.cpp to systems
not handled by the existing conditionals.
Some system headers define __constructor and __destructor macros (for
Clang attributes constructor and destructor). While this is badly
behaved, it is easy for libc++ to work around this issue.
These tests were only being run when _LIBCPP_DEBUG was defined, which
isn't the case by default when we run the test suite. In other words,
all these debug mode tests were never being run. This commit makes sure
they are run, and in some cases, extracts them into a file under test/libcxx
to separate them from the Standard tests.
Differential Revision: https://reviews.llvm.org/D88836
This reverts commit c7d4aa711a. I am still investigating the issue,
but it looks like that commit has an interaction with ld64 that causes
new/delete weak re-exports not to work properly anymore. This is weird
because this commit did not touch the exports of new/delete -- I am
still investigating.
The debug mode always had three possibilities:
- _LIBCPP_DEBUG is undefined => no assertions
- _LIBCPP_DEBUG == 0 => some assertions
- _LIBCPP_DEBUG == 1 => some assertions + iterator checks
This was documented that way, however the code did not make this clear
at all. The discrepancy between _LIBCPP_DEBUG and _LIBCPP_DEBUG_LEVEL
was especially confusing. I reworked how the various macros are defined
without changing anything else to make the code clearer.
This seems to have been added a long time ago as a temporary help
for debugging some <regex> issue, but it's really the same as
_LIBCPP_EXTERN_TEMPLATE.
This is a partial revert of D62155. Rather than copying libc++ headers
into the build directory to be later overwritten by the final headers,
use -isystem flag to access libc++ headers during CMake checks. This
should address the occasional flake we've seen, especially on Windows
builders where CMake fails to overwrite __config with the final version.
Differential Revision: https://reviews.llvm.org/D88454
This is a temporary workaround until the new/delete situation is made
better (i.e. we don't include new/delete in both libc++ and libc++abi
by default).
Instead of managing two copies of the symbol lists, reuse the same list
in libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D88623
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
After rebasing my trivially-relocatable branch, this behavior was broken...
but no libc++ unit test caught it! Add a regression test specifically for
erasing out of a vector.
Differential Revision: https://reviews.llvm.org/D88421
This flag is the default in libtool on Darwin, and it's not supported
by llvm-libtool-darwin causing a build failure.
Differential Revision: https://reviews.llvm.org/D88449
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
The CONDUIT_TOKEN is already taken from the environment. Also, disable
reporting back to Phabricator for now until we're ready to start spamming
the results back. This still needs a bit of testing.
This commit adds basic files and scripts that are used for the Buildkite
pre-commit CI setup. This was tested to mostly work on a fork of llvm-project,
however some adjustments will have to be made as we complete the real
setup.
fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we must use
enable_if<...>::type.
This reverts commit fdc41e11f9. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45: error: no template named 'enable_if_t'; did you mean 'enable_if'?
template <class _Stream, class _Tp, class = enable_if_t<
Still investigating what's causing this and reverting in the meantime to get
the bots green again.
Libc++ had an issue where nonsensical code like
decltype(std::stringstream{} << std::vector<int>{});
would compile, as long as you kept the expression inside decltype in
an unevaluated operand. This turned out to be that we didn't implement
LWG1203, which clarifies what we should do in that case.
rdar://58769296
This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.
Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.
Differential Revision: https://reviews.llvm.org/D68364
Mitsuru Kariya reported the map operations insert_or_assign with a hint
violates the complexity requirement. The function no longer uses a lower_bound,
which caused the wrong complexity.
Fixes PR38722: [C++17] std::map::insert_or_assign w/ hint violate complexity requirements
Differential Revision: https://reviews.llvm.org/D62779
We don't support GCC in C++03 mode, and Clang provides variadic templates
even in C++03 mode. So there's effectively no supported compiler that
doesn't support variadic templates.
This effectively gets rid of all uses of _LIBCPP_HAS_NO_VARIADICS, but
some workarounds for the lack of variadics remain.
When statically linking libc++ on some systems, the streams are not
initialized early enough, which causes all kinds of issues. This was
reported e.g. in http://llvm.org/PR28954, but also in various open
source projects that use libc++.
Fixes http://llvm.org/PR28954.
Differential Revision: https://reviews.llvm.org/D31413
Otherwise, we're declaring a non-static member function, and that
gives errors in C++11 because of the change of semantics between
C++11 and C++14 for non-const constexpr member functions.
This was always intended to be a friend declaration.
https://llvm.org/PR45099 notes (correctly) that we're inconsistent in memory
allocation in `std::any`. We allocate memory with `std::allocator<T>::allocate`,
construct with placement new, destroy by calling the destructor directly, and
deallocate by calling `delete`. Most of those are customizable by the user,
but in different ways.
The standard is silent on how these things are to be accomplished.
This patch makes it so we use `allocator_traits<allocator<T>>` for all
of these operations (allocate, construct, destruct, deallocate).
This is, at least, consistent.
Fixes https://llvm.org/PR45099.
Differential Revision: https://reviews.llvm.org/D81133
This test tries to create a 2 GiB std::string, catching the bad_alloc
exception if the allocation fails. However, for no-exceptions builds
there is no way for the error to be reported, so this crashes with a
null pointer dereference.
Differential revision: https://reviews.llvm.org/D87682
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
This patch was previously reverted in ed653184ac because it was missing
some UNSUPPORTED markup for older compilers. This commit adds it.
Differential Revision: https://reviews.llvm.org/D65721
The standard does not require the constructor `strstreambuf(streamsize alsize_arg = 0)`
leave the stream array unallocated when called with parameter `alsize_arg > 0`.
Conformant implementations of this constructor may allocate minimal `alsize_arg`
number of bytes forcing `str()` method to return non-null pointer.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D72465
cppreference lists the support for this paper as partial.
I found 4 functions which the paper marks as `constexpr`,
but did not use the appropriate macro.
Differential Revision: https://reviews.llvm.org/D84275
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D65721
In C++20, since P0896R4, std::ostream_iterator and std::ostreambuf_iterator
must have std::ptrdiff_t instead of void as a difference_type.
Tests by Casey Carter (thanks!).
Differential Revision: https://reviews.llvm.org/D87459
Instead, use with_system_cxx_lib with various compile-only tests to ensure
that we're getting compile-time errors, as expected. This follows the
lead of ec46cfefe8.
Target triples may contain a dash in the platform name (e.g.
"aarch64-arm-none-eabi"). Account for it when splitting the triple
into components.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D87508
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
The benchmarks expect to be built in C++17 or newer, but this
isn't always how CMake configures the C++ dialect. Instead
we need to explicitly set the CXX_STANDARD target property.
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D87189
Currently the libcxx/atomics/ext-int.verify.cpp test fails when run with
-std=c++03 because there's an extra error due to using list initialization. Fix
this by using parentheses instead.
D56913 introduced the _LIBCPP_FREESTANDING macro and guarded its
definition by:
#ifndef __STDC_HOSTED__
# define _LIBCPP_FREESTANDING
#endif
However, __STDC_HOSTED__ is defined as 0 in freestanding implementations
instead of undefined, which means that _LIBCPP_FREESTANDING would never
get defined. This patch corrects the above as:
#if __STDC_HOSTED__ == 0
# define _LIBCPP_FREESTANDING
#endif
Differential Revision: https://reviews.llvm.org/D86055
This commit re-applies 99f3b231cb, which was reverted in 8142425727
because it broke the modules build. The modules failure was a circular
dependency between the Darwin module and __config. Specifically, the
issue was that if <__config> includes a system header, the std_config
module depends on the Darwin module. However, the Darwin module already
depends on the std_config header because some of its headers include
libc++ headers like <ctype.h> (they mean to include the C <ctype.h>,
but libc++ headers are first in the header search path).
This is fixed by moving the workaround to <ctime> only.
https://llvm.org/PR47208
rdar://68157284
This reverts commit 99f3b231cb. It breaks
libcxx/modules/stds_include.sh.cpp on macOS as the new include to sys/cdefs.h
causes a dependency from __config to the Darwin module (which already has
a dependency on __config). This cyclic dependency breaks compiling the std
module which breaks compiling pretty much every program with ToT libc++ and
enabled modules.
I'll revert for now to get the bots green again. Sorry for the inconvenience.
There are currently some failures caused by this change internally. I'm working
to debug them and hopefully these series of patches should be recommitted by
the end of the week.
Thank you to Micheal Park for the contributions, and for allowing the temporary
rollback.
The commits reverted by this change are:
7d15ece79ce0ec7a020602197f7e50a175a96517
timespec_get is not available in Apple SDKs when (__DARWIN_C_LEVEL >= __DARWIN_C_FULL)
isn't true, which leads to libc++ trying to import ::timespec_get into
namespace std when it's not available. This issue has been reported to
Apple's libc, but we need a workaround in the meantime.
https://llvm.org/PR47208
rdar://68157284
Fix compilation of libcxx when using -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY. Target `cxx_external_threads` gets linked to `cxx-headers` to include all needed headers and flags.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D86773
A parameter pack is deemed to be uncaptured, which is bogus... but it seems to
be because it's within an expression that involves `decltype` of an uncaptured
pack or something: https://godbolt.org/z/b8z3sh
Drive-by fix for uglified name.
Differential Revision: https://reviews.llvm.org/D86827
This commit adds the first from-scratch configuration files for running
the libc++ test suite without using the old configuration:
- libcxx-trunk-shared.cfg.py:
Runs the test suite against a trunk libc++ shared library.
- libcxx-trunk-static.cfg.py:
Runs the test suite against a trunk libc++ static library.
Differential Revision: https://reviews.llvm.org/D81866
This implements the part of P0619R4 related to the default allocator.
This is incredibly important, since otherwise there is an ABI break
between C++17 and C++20 w.r.t. the default allocator's size_type on
platforms where std::size_t is not the same as std::make_unsigned<std::ptrdiff_t>.
This fixes a mismatched visibility attribute on the call operator in
addition to making the code clearer. Given this is a simple lambda
in essence, the intent has always been to give it inline visibility.
Fix compilation with -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY when using clang. Now linking target 'cxx_external_threads' with 'cxx-headers'. Fix mismatching visibility for `libcpp_timed_backoff_policy` function in file <__threading_support>.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D86598
We're (temporarily) disabling ExtInt for the '__atomic' builtins so we can better design their behavior later. The idea is until we do an audit/design for the way atomic builtins are supposed to work with _ExtInt, we should leave them restricted so they don't limit our future options, such as by binding us to a sub-optimal implementation via ABI.
Example after this change:
$ cat test.c
void f(_ExtInt(64) *ptr) {
__atomic_fetch_add(ptr, 1, 0);
}
$ clang -c test.c
test.c:2:22: error: argument to atomic builtin of type '_ExtInt' is not supported
__atomic_fetch_add(ptr, 1, 0);
^
1 error generated.
Differential Revision: https://reviews.llvm.org/D84049
We don't support GCC in C++03 mode, and Clang provides rvalue references
even in C++03 mode. So there's effectively no supported compiler that
doesn't support rvalue references.
Differential Revision: https://reviews.llvm.org/D84943
This change fixes errors reported by Control Flow Integrity (CFI) checking when using `std::packaged_task`. The errors mostly stem from casting the underlying storage (`__buf_`) to `__base*`, even if it is uninitialized. The solution is to wrap `__base*` access to `__buf_` behind a getter marked with _LIBCPP_NO_CFI.
Differential Revision: https://reviews.llvm.org/D82627
Add shared_ptr tests where the element type and pointer type aren't 'convertible' but are 'compatible'.
Responding to a comment from D81414.
Differential Revision: https://reviews.llvm.org/D81532
Block.h is a pretty common name, which can lead to nasty collisions with
user provided headers. Since we're only getting a few simple declarations
from the header, it's better to declare them manually than to include the
header.
rdar://66384326
Differential Revision: https://reviews.llvm.org/D85035
As explained in https://gitlab.kitware.com/cmake/cmake/-/issues/21045,
both branches of an $<IF> generator expression are evaluated eagerly
by CMake. As a result, if the non-selected branch contains an invalid
generator expression (such as getting the OUTPUT_NAME property of a
non-existent target), a hard error will occur.
This failed builds using the cxxrt ABI library, which doesn't create
a CMake target currently.
Louis Dionne