Instead of using a temporary `string` in `__vformat_to_wrapped` use a new
generic iterator. This aids to reduce the number of template instantions
and avoids using a `string` to buffer the entire formatted output.
This changes the type of `format_context` and `wformat_context`, this can
still be done since the code isn't ABI stable yet.
Several approaches have been evaluated:
- Using a __output_buffer base class with:
- a put function to store the buffer in its internal buffer
- a virtual flush function to copy the internal buffer to the output
- Using a `function` to forward the output operation to the output buffer,
much like the next method.
- Using a type erased function point to store the data in the buffer.
The last version resulted in the best performance. For some cases there's
still a loss of speed over the original method. This loss many becomes
apparent when large strings are copied to a pointer like iterator, before
the compiler optimized this using `memcpy`.
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110495
I suspect this is a remnant of the times when we were not comfortable
using Clang's C++11/14 extensions everywhere, but now we do, so we can
use _BoolConstant instead and get rid of the macro.
Differential Revision: https://reviews.llvm.org/D122351
In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because since C++20 there is also `identity`, which isn't a type trait.
Reviewed By: ldionne, Mordante, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122017
I audited all uses of _LIBCPP_ASSERT to make sure that we only used it
for "basic assertions", i.e. assertions with constant-time conditions.
I also audited all uses of _LIBCPP_DEBUG_ASSERT to make sure we used it
only for debug-mode assertions, and in one case had to change for
_LIBCPP_ASSERT instead.
As a fly-by, I also changed a couple of tests against nullptr or 0 to
be more explicit.
After this patch, all uses of _LIBCPP_ASSERT should be with constant-time
conditions, and all uses of _LIBCPP_DEBUG_ASSERT should be with conditions
that we only want to check when the debug mode is enabled.
Differential Revision: https://reviews.llvm.org/D122395
Add missing commit SHAs in a few cases, and use "All Platforms" when
the change affected all platforms instead of explicitly listing the
platforms, since there's too many to list exhaustively.
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even though it's
not nearly as bad as the removed constructors fixed by D121626).
Differential Revision: https://reviews.llvm.org/D122184
This patch makes it possible to pass a CMake option to one of the runtimes
for all targets being built. Basically, any option that starts with the
name of a runtime project being built will be forwarded as-is to the
sub-build. This is useful for customizing a sub-build for all targets.
Differential Revision: https://reviews.llvm.org/D121822
The test fails on AIX due to it expecting an error as on Linux. However, as on
other non-Linux systems symlinks permissions are supported so expect an empty
error code.
Reviewed By: daltenty, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D121140
It turns out that we had never been enabling it anyways, since the
LIBCXX_TEST_PARAMS parameter was not being passed from the bootstrapping
build to the libc++ and libc++abi builds. Furthermore, it looks like the
per-target include directories used by the bootstrapping build by default
are incompatible with our current modulemap, since __config_site doesn't
live in the directory that our modulemap claims.
This disables modules in our bootstrapping CI job to unblock D121822,
but we should work on fixing the underlying issue once we're able to
pass those configuration options to our bootstrapping build.
These are the last™ changes to the tests for constexpr preparation.
Reviewed By: Quuxplusone, #libc, Mordante
Spies: Mordante, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120951
Before it only accepted one output iterator type. Now it accepts all
output iterator types as required by BasicFormatter.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D120916
Addresses LWG 3548 which mandates that when shared_ptr is being constructed from a unique_ptr, the unique_ptr's deleter should be moved and not copied.
Reviewed By: #libc, philnik, EricWF
Differential Revision: https://reviews.llvm.org/D119159
Changes in [P0896](https://wg21.link/p0896):
- add `disable_sized_sentinel_for`;
- add `iter_move` and `iter_swap`;
- add a `requires` clause to the `operator->`;
- add `iterator_concept`;
- check that the `Iterator` template parameter is a bidirectional
iterator;
- add constraints to all comparison operators;
- change the definitions of `iterator_category`, `value_type`,
`difference_type` and `reference` (changes to `iterator_category` were
already implemented).
Also add a few forgotten things to the `reverse_iterator` synopsis
(notably the spaceship operator).
Differential Revision: https://reviews.llvm.org/D120180
This tests the same QoI issue as the existing STL Classic test,
but for the Ranges algorithms. Also, do the same thing for all
the algorithms that take projections.
I found a few missing algorithms and added them to the existing test, too. `std::find_first_of` currently fails; I should look at why that is (and in particular, what is it doing weird that //makes// it inconsistent with the entire rest of libc++?).
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D121265
We've been meaning to remove support for the legacy testing configuration
for a long time. This patch switches the default from the legacy config
to the appropriate new-style configuration based on a few hints.
We've been running with the new-style configuration for more than a year
in our CI, however it's possible that this will uncover issues with some
users that run the tests on platforms that we don't support yet with the
new-style configs. Unfortunately, there is no way to know about it other
than to land this patch and see whether anything breaks.
Differential Revision: https://reviews.llvm.org/D121632
This reverts commit 406d418c0c.
Our regular bots are now using clang-13. The previous set will remain
online for a while to check reviews that haven't rebased to include
this change yet.
Differential Revision: https://reviews.llvm.org/D121894
In the new-style testing configurations, we were hardcoding paths to the
`include` and `lib` directories, which was incorrect but always went
unnoticed because the hardcoded values always happened to match the
actual value.
When using new-style configs with the bootstrapping build, this falls
appart -- and we never noticed this because the bootstrapping build was
still using old style configs.
This patch removes the %{install} substitution, which makes it too
tempting to hardcode installation paths, and it also switches the
bootstrapping build to actually using new-style configs like we
always intended to do.
Differential Revision: https://reviews.llvm.org/D121700
In 7fb40e1569, I changed the availability for bad_optional_access and
friends from macOS 10.14 to 10.13 after conducting an investigation on
old dylibs. It turns out that macOS 10.13 did have bad_optional_access,
however the dylib on iOS didn't match the dylib on macOS, so those
exception classes were only introduced in iOS 12.
Thanks to Aditya Kumar for noticing this.
Differential Revision: https://reviews.llvm.org/D121735
It's the role of the C++ ABI library to install its own headers, not libc++.
This fixes an existing issue causing spurious CI failures where both libc++
and libc++abi would try to install <cxxabi.h> & friends in the same location,
leading to failures during the installation step.
Differential Revision: https://reviews.llvm.org/D121706
This should make CI consistent on all the compilers we support. Most of
this patch is working around various warnings emitted by GCC in our code
base, which are now being shown when we compile the tests.
After this patch, the whole test suite should be warning free on all
compilers we support and test, except for a few warnings on GCC that
we silence explicitly until we figure out the proper fix for them.
Differential Revision: https://reviews.llvm.org/D120684
Back in 3a208c6894, we implemented the range-based constructor for <span>.
However, in doing so, we removed a previous non-standard constructor that
we provided before shipping <ranges>. Unfortunately, that breaks code that
was relying on a range-based constructor until we ship all of <ranges>.
This patch reintroduces the old non-conforming constructors and tests
that were removed in 3a208c6894 and uses them whenever <ranges> is
not provided (e.g. in LLVM 14). This is only a temporary workaround
until we enable <ranges> by default in C++20, which should hopefully
happen by LLVM 15.
The goal is to cherry-pick this workaround back to the LLVM 14 release
branch, since I suspect the constructor removal may otherwise cause
breakage out there, like the breakage I saw internally.
We could have avoided this situation by waiting for C++20 to be finalized
before shipping std::span. For example, we could have guarded it with
something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from
accidentally starting to depend on it before it is stable. We did not
have these mechanisms when std::span was first implemented, though.
Differential Revision: https://reviews.llvm.org/D121626
The class `__dir_stream` is currently declared in two places: as a
top-level forward declaration in `directory_iterator.h`, and as a friend
declaration in class `directory_entry`, in `directory_entry.h`.
The former has a `_LIBCPP_HIDDEN` attribute, but the latter does not,
causing the Firefox build to complain about the visibility not matching
the previous declaration. This is because Firefox plays games with
pushing and popping visibility.
Work around this by making both `__dir_stream` declarations consistently
use `_LIBCPP_HIDDEN`.
Reviewed By: ldionne, philnik, #libc
Differential Revision: https://reviews.llvm.org/D121639
Prior to this patch, there was no distinction between tests that check
basic assertions and tests that check full-fledged iterator debugging
assertions. Both were disabled when support for the debug mode is not
provided in the dylib, which is stronger than it needs to be.
Furthermore, all of the tests using "debug_macros.h" that contain more
than one assertion in them were broken -- any code after the first
assertion would never be executed.
This patch refactors all of our assertion-related tests to:
1. Be enabled whenever they can, i.e. basic assertions tests are run
even when the debug mode is disabled.
2. Use the superior `check_assertion.h` (previously `debug_mode_helper.h`)
instead of `debug_macros.h`, which allows multiple assertions in the
same program.
3. Coalesce some tests into the same file to make them more readable.
4. Use consistent naming for test files -- no more db{1,2,3,...,10} tests.
This is a large but mostly mechanical patch.
Differential Revision: https://reviews.llvm.org/D121462
It turns out that the whole header is only enabled in C++20 and above,
so these checks were redundant (and always true).
Differential Revision: https://reviews.llvm.org/D121604
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
We don't need preprocessor logic to exclude those declarations when compiling for
the Windows App Store, because that is handled by using_if_exists now.
Differential Revision: https://reviews.llvm.org/D108632
Instead of carrying around #ifdefs to determine whether those functions
are available on the platform, unconditionally use the using_if_exists
attribute to import it into namespace std only when available. That was
the purpose of this attribute from the start.
This change means that trying to use libc++ with an old SDK (or on an
old platform for platforms that ship system headers in /usr/include)
will require a recent Clang that supports the using_if_exists attribute.
When using an older Clang or GCC, the underlying platform has to support
a C11 standard library.
Differential Revision: https://reviews.llvm.org/D108203
As a fly-by fix, also move it closer to where it is needed, and add a
comment explaining the existence of this weird function.
Differential Revision: https://reviews.llvm.org/D121231
operator-> is not a requirement for most iterators, so remove it. To
account for this change, the `common_iterator.operator->` test needs to
be refactored quite a bit -- improve test coverage while we're at it.
Differential Revision: https://reviews.llvm.org/D118400
Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
This reverts commit 276ca873. That commit has quite a history at this
point. It was first landed in dbc647643577, which broke std::shared_ptr<T const>
and was reverted in 9138666f5. It was then re-applied in 276ca873, with
the std::shared_ptr issue fixed, but it caused widespread breakage at
Google (which suggests it would cause similar breakage in the wild too),
so now I'm reverting again.
Instead, I will add a escape hatch that vendors can turn on to enable
the extension and perform a phased transition over one or two releases
like we sometimes do when things become non-trivial.
These tests don't seem specific to the debug mode, so it makes sense to
run them even when the debug mode is disabled. When we run with the debug
mode enabled, we'll get the out-of-bounds checking that this test seems
to be concerned with.
Differential Revision: https://reviews.llvm.org/D121241
Based on review comments in D97705 applied some code cleanups in
<charconv>. The header now uses a more recent libc++ style.
Reviewed By: Quuxplusone, #libc, philnik
Differential Revision: https://reviews.llvm.org/D121223
LIBCXX_ENABLE_ASSERTIONS does not have any relationship to the `assert`
macro -- it only controls assertions that are internal to the library.
Playing around with `NDEBUG` only muddies the picture further than it
already is.
Also, remove a failing assertion in the benchmarks. That assertion had
never been exercised because we defined `NDEBUG` manually, and it was
failing since we introduced the ability to generate a benchmark vector
with the Quicksort adversary ordering (which is obviously not sorted).
This was split off of https://llvm.org/D121123.
Differential Revision: https://reviews.llvm.org/D121244
Those older versions used a different monetary decimal separator.
To avoid unnecessary churn to support that, just XFAIL the test
on those older versions. (Up until
df1e43c496, the whole test was XFAILed
on all versions of glibc.)
Differential Revision: https://reviews.llvm.org/D120979
On Windows, constants like F::alpha and F::print are bitmasks
consisting of multiple bits (e.g. F::alpha consisting of both the
bits F::upper and F::lower). In such a case, we can't check that
all the bits from all the expected constants are set. Instead,
check that (p[i] & mask) != 0 returns the expected value.
Differential Revision: https://reviews.llvm.org/D120802
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
This is a re-application of dbc647643577, which was reverted in 9138666f5
because it broke std::shared_ptr<T const>. Tests have now been added and
we've made sure that std::shared_ptr<T const> wouldn't be broken in this
version.
Differential Revision: https://reviews.llvm.org/D120996
As a fly-by fix, enable the complexity-changing assertions in __debug_less
only when the full debug mode is enabled, since debugging level 0 is usually
understood to only contain basic assertions that do not change the complexity
of algorithms.
Differential Revision: https://reviews.llvm.org/D121129
These are some checks that make sense in libc++ IMO. The checks after `#TODO: investigate these checks` are candidates, but they can't be enabled without some cleanup.
Reviewed By: ldionne, #libc
Spies: aheejin, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120925
Saves one move in each case, which is basically nothing perf-wise;
this is more about simplifying the code.
Differential Revision: https://reviews.llvm.org/D121130
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.
This makes sure that the symbols are properly dllexported in such
a configuration scenario.
Differential Revision: https://reviews.llvm.org/D120982
This extension is a portability trap for users, since no other standard
library supports it. Furthermore, the Standard explicitly allows
implementations to reject std::allocator<cv T>, so allowing it is
really going against the current.
This was discovered in D120684: this extension required `const_cast`ing
in `__construct_range_forward`, a fishy bit of code that can be removed
if we don't support the extension anymore.
Differential Revision: https://reviews.llvm.org/D120996
AIX print -0.0 , inf, nan differently, which are causing the test
failures. We are OK for most other tests.
This patch remove the tests related these limitations conditionally on AIX,
so that we can enable the other tests to avoid losing test coverage.
The general direction is:
```
if strings don't differ between environments, keep the string literal "INF" and the padding, instead of folding them into variables.
```
Reviewed By: ldionne, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D120448
Move `__quoted_output_proxy` into the one file that uses it.
A `const char*` has no associated traits class, so `std::quoted("literal")`
should be printable into any basic_ostream regardless of traits.
Use hidden-friend `operator<<` and `operator>>`, since we're permitted to.
(The exact signature is unspecified because the class itself is unspecified.)
We shouldn't support `std::quoted("literal")` in C++03 or C++11 mode.
(We do need `std::__quoted(s)` and `std::__quoted(cs)` in C++11 mode,
because they're used by `std::__fs::filesystem::path`.)
Differential Revision: https://reviews.llvm.org/D120135
Zero-sized types are a GCC extension, also supported by Clang.
In theory it's already invalid to `delete` a void pointer or a
pointer-to-incomplete, so we shouldn't need any special code
to catch those cases; but in practice Clang accepts both
constructs with just a warning, and GCC even accepts `sizeof(void)`
with just a warning! So we must keep the static_asserts.
The hard errors are tested in `unique_ptr_dltr_dflt/*.compile.fail.cpp`.
In ranges::begin/end, check `sizeof >= 0` instead of `sizeof != 0`,
so as to permit zero-sized types while still disallowing incomplete
types.
Fixes#54100.
Differential Revision: https://reviews.llvm.org/D120633
I believe the origin issue in PR31864 has been addressed by https://reviews.llvm.org/D59566.
As discussed in https://github.com/llvm/llvm-project/issues/53840, `ATOMIC_LLONG_LOCK_FREE == 2` sometimes is not consistent with `std::atomic<long long>::is_always_lock_free`, since the macro takes `long long`'s ABI alignment into account. https://reviews.llvm.org/D28213 proposed we should not rely on ABI alignment of types, thus we have consistent `ATOMIC_LLONG_LOCK_FREE` and `std::atomic<long long>::is_always_lock_free` on x86's old cpu. Currently, I plan to move on to remove the workaround which should have been addressed and don't want to break current tests.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119931
This change makes the behavior of `<experimental/coroutine>` consistent with other headers that only work conditionally.
Reviewed By: ldionne, #libc
Spies: Mordante, ChuanqiXu, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D119964
Previously, this test snippet would report incorrect information:
F::mask m;
std::wstring in(L"\u00DA"); // LATIN CAPITAL LETTER U WITH ACUTE
f.is(in.data(), in.data() + 1, &m);
// m & F::lower would be set
The single-character version of the `is` function wasn't
affected by this issue though.
Define `_LIBCPP_CTYPE_MASK_IS_COMPOSITE_ALPHA` for Windows,
as the `alpha` / `_ALPHA` constant is a mask consisting of
multiple bits set, which avoids setting `alpha` whenver any
of the bits is set, in the `do_is` implementation.
On Windows, with the "C" locale, wchars are classified according
to their Unicode interpretation, just as in the en_US.UTF-8 locale on
all platforms.
Due to the differing classification of some characters, the
`scan_is` and `scan_not` tests are quite annoying to fix, thus just
ifdef out some of the tests for the "C" locale there - the code gets
tested with the more standard en_US.UTF-8 locale anyway.
Differential Revision: https://reviews.llvm.org/D120796
Fixes LWG3656, "Inconsistent bit operations returning a count".
https://cplusplus.github.io/LWG/issue3656
The fix has been approved for C++23 and left to vendors' discretion
in C++20 (but it sounds like everyone's on the same page that
of course it should be DR'ed back to C++20 too).
Differential Revision: https://reviews.llvm.org/D120444
This is slightly more user-visible than D119894, because the user is
expected to touch `__wrap_iter` directly. But the affected ctors are
non-public, so the user was never expected to be actually calling them.
And I didn't intentionally omit this from D119894; I just didn't
think of it.
Differential Revision: https://reviews.llvm.org/D120937
In the en_US locale on Windows, negative currency amounts is formatted
as "($0.01)" instead of "-$0.01".
Differential Revision: https://reviews.llvm.org/D120799
Change the tests to use the base friend function instead of members.
Also changed some types to have a base friends instead of members.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D120742
`basic_ios` delays initialization of `__fill_` to `widen(' ')` until `fill()` is called. But, `fill(char_type)` is missing this logic, so the fill character does not get initialized to whitespace if `fill(char_type)` is called first. This patch adds this logic to `fill(char_type)`.
Reviewed By: #libc, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D120751
Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.
The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).
Reviewed By: #libc, ldionne, #libc_abi
Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D118616
This takes care of normalizing newlines back to single LF instead
of CRLF.
Fix up a couple tests that accidentally pass binary data to stdout.
Differential Revision: https://reviews.llvm.org/D120623
Note, reducing ios.width() in put_long_double instead of using variable
padding, when using a variable width symbol. Some of those tests didn't
actually trigger any padding in the existing form, with a longer
currency symbol; reduce the width so there's no actual padding with the
slightly shorter currency symbol either.
The tests for the international currency symbol use the same amount of
padding on all platforms, so they still exercise the padding properly.
Differential Revision: https://reviews.llvm.org/D120317
The old expected behaviour was specific to Apple platforms,
while Glibc, Windows and FreeBSD collate differently (ignoring
case). Make the old tested behaviour a special case for Apple
platforms, and make the default case the one used by the other
three.
In clang-cl/DLL configurations, the test is hit by
https://llvm.org/PR41018 (making the test fail to link).
Differential Revision: https://reviews.llvm.org/D120797
In the en_US locale on Windows, negative currency amounts is formatted
as "($0.01)" instead of "-$0.01".
Adjust the test references accordingly, making these tests pass.
Differential Revision: https://reviews.llvm.org/D120798
As part of https://reviews.llvm.org/D119036
(506cf6dc04), `-DNOMINMAX` was
dropped from the Windows CI configurations, replaced with a
block with `_LIBCPP_PUSH_MACROS`, `#include <__undef_macros>`
and `_LIBCPP_POP_MACROS` (and
`ADDITIONAL_COMPILE_FLAGS: -DNOMINMAX` left in two tests).
However, this workaround breaks the running the libc++ tests
against a different C++ standard library than libc++, as those
macros and that header are libc++ internals.
Therefore, reinstate `-DNOMINMAX` for clang-cl configurations
and remove the libc++ specific bits in filesystem_test_helper.h.
Differential Revision: https://reviews.llvm.org/D120478
Previously, all the output from the tests were placed directly in
the build directory. The tests produce a couple directories named
`__config_{exec,cache,src}__` which are easy to distinguish, but
the output from the individual tests are placed in subdirectories
named `std` or `libcxx`. Especially the build output from libcxx
tests ends up conflated in the same directories as are used for
building libcxx with cmake.
Differential Revision: https://reviews.llvm.org/D120479
AIX's system header provides these C++ overloads for compatibility with
older XL C++ implementations, but they can be disabled by defining
__LIBC_NO_CPP_MATH_OVERLOADS__ since AIX 7.2 TL 5 SP 3.
Since D109078 landed clang will define this macro when using libc++ on
AIX and we already run the lit tests with it too. This change will
enable the overloads in libc++'s math.h and we'll continue to require
the compiler to define the macro going forward.
Reviewed By: ldionne, jsji, EricWF
Differential Revision: https://reviews.llvm.org/D102172
co-authored-by: Jason Liu <jasonliu.development@gmail.com>
These printf()s fail to compile like so on hexagon:
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:94:23: error: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Werror,-Wformat]
printf("%u ", elem);
~~ ^~~~
%lu
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:569:56: error: format specifies type 'unsigned int' but the argument has type 'uint32_t' (aka 'unsigned long') [-Werror,-Wformat]
fprintf(stderr, "%s failed for 0x%08X\n", msg, bits);
~~~~ ^~~~
%08lX
.../tools/llvm-top/libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp:1096:43: error: format specifies type 'unsigned int' but the argument has type 'unsigned long' [-Werror,-Wformat]
printf("Randomized test cases: %u\n", PrefixesToTest * Fractions);
~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
%lu
Differential Revision: https://reviews.llvm.org/D120532
Notably the following ctors remain non-explicit because they
are used as implicit conversions in too many places:
* __debug_less(_Compare&)
* __map_iterator(_TreeIterator)
* __map_const_iterator(_TreeIterator)
* __hash_map_iterator(_HashIterator)
* __hash_map_const_iterator(_HashIterator)
Differential Revision: https://reviews.llvm.org/D119894
These tests are hit hard by a bug that is fixed in a newer version
of UCRT. Add a test for the specific bug, and XFAIL the tests if
that bug is present (as it is in CI).
Split out hex formatting of floats to separate test files, that
are excluded with `XFAIL: msvc`. (Based on reading the C standard for
printf formatting, it seems like this isn't necessarily a proper bug
in printf, but just a case of differing optional behaviour.)
Differential Revision: https://reviews.llvm.org/D120022
All supported compilers have implemented this feature.
Therefore use the language version instead of the feature macro.
Reviewed By: #libc, philnik, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119865
Add an explicit LIBCXX_CXX_ABI=system-libcxxabi option for linking to
system-installed libc++abi. This fixes the ability to link against one
when building libcxx via the runtimes build, as otherwise the build
system insists on linking into in-tree targets.
Differential Revision: https://reviews.llvm.org/D119539
Instead, folks can use the equivalent variables provided by CMake
to set those. This removal aims to reduce complexity and potential
for confusion when setting the target triple for building the runtimes,
and make it correct when `CMAKE_OSX_ARCHITECTURES` is used (right now
both `-arch` and `--target=` will end up being passed, which is downright
incorrect).
Differential Revision: https://reviews.llvm.org/D112155
This commit reverts 5aaefa51 (and also partly 7f285f48e7 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.
Differential Revision: https://reviews.llvm.org/D120683
This takes care of normalizing newlines back to single LF instead
of CRLF.
This on itself breaks on a couple tests that accidentally seem to
be writing binary data to stdout; make sure those cases are piped
to /dev/null instead of actually written to a terminal.
Differential Revision: https://reviews.llvm.org/D120623
libc++abi should be responsible for installing its own headers, it
doesn't make sense for libc++ to be responsible for it.
Differential Revision: https://reviews.llvm.org/D101458
International currency symbols (like USD, EUR) are returned with a
trailing space, like "USD ", on previously supported Unix platforms.
On Windows, the locales return them without a trailing space.
Also adjust the test for expecting a different unicode sequence for
the national currency symbol for ru_RU.UTF-8 and zh_CN.UTF-8.
Differential Revision: https://reviews.llvm.org/D120547
`uniform_int_distribution<T>` is UB unless `T` is one of the non-character,
non-boolean integer types (`short` or larger). However, libc++ has never
enforced this. D114129 accidentally made `uniform_int_distribution<bool>`
into an error. Make it now *intentionally* an error; and likewise for the
character types and all user-defined class and enum types; but permit
`__[u]int128_t` to continue working.
Apply the same static_assert to all the integer distributions.
Differential Revision: https://reviews.llvm.org/D114920
This follows the general direction of D118736 that
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES` does *not* guard anything outside
of the `std::ranges::` namespace itself. This means we must permit
`ranges::less` etc. in no-ranges mode; that seems fine to me.
Differential Revision: https://reviews.llvm.org/D120139
According to Linux documentation (see e.g. https://linux.die.net/man/3/closedir):
> A successful call to `closedir()` also closes the underlying file
> descriptor associated with `dirp`.
Thus, calling `close()` after a successful call to `closedir()` is at
best redundant. Worse, should a different thread open a file in-between
the calls to `closedir()` and `close()` and get the same file descriptor,
the call to `close()` might actually close a different file than was
intended.
rdar://89251874
Differential Revision: https://reviews.llvm.org/D120453
Windows UCRT has got a bug in older versions (present in CI), where
it successfully does set a locale named
`for_sure_this_is_not_an_existing_locale`. By adjusting the tested
locale name to `forsurethisisnotanexistinglocale`, that test works
as expected, failing to set the locale.
The bug is reported upstream at
https://developercommunity.visualstudio.com/t/setlocale-succeeds-for-bogus-locale-names-in-older/1652241,
but as it already is working correctly in newer versions, no action
was prompted there.
We could of course add a bug detection in features.py like other
existing `broken-*` features, but that would seem kinda
pointless as it would be doing exactly what this test does.
Instead just adjust the tested dummy locale name.
This bit was approved to be committed on its own, in
https://reviews.llvm.org/D120546 (which is left open to follow up on
review of the rest of that patch).
The zh_CN.UTF-8 locale on Glibc has got `n_sign_posn == 4` (which means
having the negative sign just after the currency symbol), but has
`int_n_sign_posn == 1` (which means before the string).
On Windows, there's no separate `int_n_sign_posn` field, so the same
`n_sign_posn` (which is 4 there too) is used for international currency
formatting too. This makes the ordering for the international case on
Windows be the same as for the national one right above it.
On Apple platforms, the fr_FR.UTF-8 locale has got `n_sign_posn == 2`
but `p_sign_posn == 1`, giving a different order for the French locale
for the negative format.
On Apple platforms for the zh_CN.UTF-8 locale, both `n_sign_posn` and
`int_n_sign_posn` are 4, but `p_sign_posn` and `int_p_sign_posn` are 1.
Differential Revision: https://reviews.llvm.org/D120550
A merge conflict in D106124 accidentally reverted this part of
b82683b2e/D110794.
> Even if these comments have a benefit in .h files (for editors that
> care about language but can't be configured to treat .h as C++ code),
> they certainly have no benefit for files with the .cpp extension.
9f5f084 (D119770) made this test pass in the Windows configuration too,
but didn't update the XFAIL accordingly.
Differential Revision: https://reviews.llvm.org/D120611
`__addr_in_range` is a non-constexpr function, so we can't call it during constant evaluation.
Reviewed By: Quuxplusone, #libc, miscco
Spies: miscco, libcxx-commits
Differential Revision: https://reviews.llvm.org/D119633
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
Differential Revision: https://reviews.llvm.org/D106124
According to POSIX.1 (and Glibc docs, and Microsoft docs), the wctob
function returns EOF on error, not WEOF. (And wctob_l should consequently
do the same.)
The previous misconception about what this function returns on errors
seems to stem from incorrect documentation in macOS, stemming from BSD
docs with the same issue. The corresponding documentation bug in FreeBSD
was fixed in 2012 in
945aab9099,
but it hasn't been fixed for macOS yet.
The issue seems to only be a documentation issue; the implementation
on macOS actually does use EOF, not WEOF:
https://opensource.apple.com/source/Libc/Libc-1439.40.11/locale/FreeBSD/wctob.c.auto.html
On most Unices, EOF and WEOF are the same value, but on Windows,
EOF is -1, while WEOF is (unsigned short)0xFFFF. By fixing this,
two tests start passing on Windows.
Differential Revision: https://reviews.llvm.org/D120088
On Windows, the en_US.UTF-8 locale returns `n_sign_posn == 0`, which
means that the sign for a negative currency is parentheses around
the whole value, instead of a leading minus.
Differential Revision: https://reviews.llvm.org/D120549
This patch marks the class _Flags as packed because the design assumes that it
is packed and a number of tests also assume that it is packed. However on AIX
the class is not packed unless it is marked as such.
Reviewed By: hubert.reinterpretcast, #libc, Mordante, ldionne, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119567
It seems that we are using wchar_t in __estimate_column_width and assume that
it is a 32 bit type. However, on AIX 32 the size of wchar_t is only 16 bits.
Changed wchar_t to uint32_t since the variable is being passed to a function
that uses uint32_t anyway.
Reviewed By: hubert.reinterpretcast, daltenty, Mordante, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119770
This fixes instances of the newly added `-Wunqualified-std-cast-call`.
(Commit 7853371146 removed unqualified `move` from the tests,
but these unqualified `move`s remained undetected in the actual headers.)
Differential Revision: https://reviews.llvm.org/D120509
This fixes issue #45084 (https://llvm.org/PR45739).
Remove unnecessary trailing spaces after the "RUB" international
currency symbol (and after the plain number in some parts of the
put_long_double test).
Both of these test files are
`XFAIL: netbsd || linux || LIBCXX-WINDOWS-FIXME`, and then have some of
their test cases commented out when `__APPLE__`. This patch comments-in
those test cases and adjusts them all to work on Apple, while leaving the
test `XFAIL`ed on NetBSD, Linux, and Windows.
Differential Revision: https://reviews.llvm.org/D120316
The unique_ptr_ret and weak_ptr_ret tests are not expected to pass on
AIX. These tests check that unique_ptr and weak_ptr are returned by
value, but on AIX, all structs are always returned by reference.
```
3.9.6 Function Return Values
...
Note: Structures of any length and character strings longer than four
bytes are returned in a storage buffer allocated by the caller. The
address of this buffer is passed as a hidden first argument in GPR3,
which causes the first explicit argument word to be passed in GPR4. This
hidden argument is treated as a formal argument and corresponds to the
first word of the argument area.
```
Reviewed By: #powerpc, daltenty, #libc, Quuxplusone, philnik
Differential Revision: https://reviews.llvm.org/D119952
Set std::numeric_limits<>::tinyness_before to true for floating point types on ARM platforms.
Section E1.3.5 in the ARMv8 Architecture Reference Manual specifies:
Underflow. The bit is set to 1 if the absolute value of the result
of an operation, produced before rounding, is less than the minimum
positive normalized number for the destination precision, and the
rounded result is inexact.
Reviewed By: #libc, majnemer, EricWF
Differential Revision: https://reviews.llvm.org/D116338
AIX's libc generates "Error -1 occurred" instead of the "Unknown Error"
expected by these test cases. Add this as expected output for AIX only.
Reviewed By: daltenty, #powerpc, #libc, zibi, Quuxplusone
Differential Revision: https://reviews.llvm.org/D119982
As suggested by the cmake warning:
CMake Warning at <...>/llvm-project/libcxx-ci/libcxx/CMakeLists.txt:289 (message):
LIBCXX_TARGET_TRIPLE is deprecated, please use CMAKE_CXX_COMPILER_TARGET instead
Depends on D119948
Differential Revision: https://reviews.llvm.org/D120038
Fixup tests that believe them to be so. Most notably including some heavy refactoring in `std/iterators/iterator.primitives/iterator.traits/cxx20_iterator_traits.compile.pass.cpp`, which now detects pointers and validates that `iterator_concept` is present only for pointers.
Differential Revision: https://reviews.llvm.org/D117368
Since Windows 10 version 1803 (10.0.17134.0) (or Windows Server 2019),
the Windows Universal C Runtime (UCRT) actually does support UTF-8
locales - they're available e.g. via the same names as commonly on Unices,
e.g. "en_US.UTF-8".
The UTF-8 locale support unfortunately has a bug which breaks a couple
tests that were passing previously. That bug is fixed in the very
latest version of the UCRT (in UCRT 10.0.20348.0, available in Windows
11 or Windows Server 2022), so it will get resolved at some point
eventually, provided that the CI environment does get upgraded to a
newer version of Windows Server.
While the net number of xfailed/passing tests in this patch is a loss,
this does allow fixing a lot more locale tests properly for Windows
in later patches.
Intentionally not touching the ISO-8859-1/2 locales used for testing;
they're not detected and tested/used right now, and fixing that up
is another project.
Differential Revision: https://reviews.llvm.org/D119930
Some jobs might not produce those, but it makes the blocks easier to
copy-paste and makes sure that if a job does produce an ABI list, it
will be updloaded in the artifacts.
Differential Revision: https://reviews.llvm.org/D120056
Also apply the same fix on glibc. This takes the test one step closer
to passing on glibc, but it still fails on the zh_CN test (which
requires a more involved fix in libc++ itself).
Differential Revision: https://reviews.llvm.org/D119791
Expect the same NAN formatting on Windows as on Glibc. (Both MSVC and
MinGW produce the same formatting there.)
The hex float formatting tests pass on MinGW, so opt in to those tests.
Document exactly what issues are remaining in Clang-cl/MSVC
configurations. (It's easily possible to make the tests pass there too,
but it requires a whole lot of small-scope ifndefs in the test file;
around 60 ifdefs in total for those both test files. Those could
be avoided if the CI environment could run with a newer version
of UCRT, but that's nontrivial to fix right away.)
Differential Revision: https://reviews.llvm.org/D119766
This patch upstreams some changes we've made internally to how we're
building the libc++ dylib on Apple platforms. The goal is still to
eventually get rid of `apple-install-libcxx.sh` entirely and have a
proper way to mirror what we do internally with just the normal CMake
configuration.
Differential Revision: https://reviews.llvm.org/D118912
This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.
Differential Revision: https://reviews.llvm.org/D119769
It actually *is* important (for structured bindings) that `get(tuple)`
be ADL-able; but that's not the point of this test in particular.
Reviewed as part of D119860.
We shouldn't be calling `rethrow_exception` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `rethrow_exception` in particular.
Reviewed as part of D119860.
We shouldn't be calling these functions via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
the ADL ability of these functions in particular.
Reviewed as part of D119860.
We shouldn't be calling `prev` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `prev` in particular.
Reviewed as part of D119860.
We shouldn't be calling `next` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `next` in particular.
Reviewed as part of D119860.
We shouldn't be calling `move` via ADL -- and neither should anybody
in the wild be calling it via ADL, so it's not like we need to test
this ADL ability of `move` in particular.
Reviewed as part of D119860.
Mark de Wever