include the invalid LIBCXX_ABI_NAMESPACE to ease debugging.
Reviewed By: #libc, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D127257
- Updates the image to use Ubuntu Jammy.
- Installs GCC-12 as preparation to migrate to that GCC version.
NOTE: This is a re-application of f2f0dba818, which was reverted
in 2b5e3ef83c due to an issue with the CI nodes. The CI nodes have
since then been updated and this appears to be fine.
Differential Revision: https://reviews.llvm.org/D126666
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).
This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.
Differential Revision: https://reviews.llvm.org/D103960
When some headers are not available because we removed features like
localization or threads, the compiler should not try to include these
headers when building modules. To avoid that from happening, add a
requires-declaration that is never satisfied when the configuration
in use doesn't support a header.
rdar://93777687
Differential Revision: https://reviews.llvm.org/D127127
This reverts commit f2f0dba818.
This Docker file doesn't work on the CI. It fails to clone the checkout.
This seems like an issue with a newer glibc on an older Docker where the
clone3() call fails.
This needs further investigation before relanding.
Get rid of the __is_trivially_copy_assignable_unwrapped helper, which
is only used in one place, and use __iter_value_type instead of
iterator_traits<T>::value_type.
Differential Revision: https://reviews.llvm.org/D127230
With the new version of Git in Ubuntu Jammy (which is now what we use in
our Docker image), we need to add `/llvm` to the list of safe directories
to avoid failures.
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
After moving the std::to_chars base 10 implementation from the dylib to
the header the integral overloads of std::to_chars are available on all
platforms.
Remove the _LIBCPP_AVAILABILITY_TO_CHARS availability macro and update
the tests.
Depends on D125704
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D125745
- Updates the image to use Ubuntu Jammy.
- Installs GCC-12 as preparation to migrate to that GCC version.
Reviewed By: ldionne, #libc, jloser
Differential Revision: https://reviews.llvm.org/D126666
This was noticed in the review of D125704. In that commit only the new
table has been adapted. This adapts the existing tables.
Note since libc++'s charconv is backported to C++11 it's not possible to
use inline constexpr variables. The were introduced in C++17.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D126887
In MinGW environments, thanks to slightly different code generation
and linker tricks, it's possible to link against a DLL C++ standard
library without dllimport attributes.
This allows using one single set of headers for linking against
either the DLL or a static library, leaving the decision entirely
up to the linking stage (where it can be switched with options like
-static-libstdc++).
This matches how libstdc++ headers work; there's no dllimport attributes
by default (unless the user has defined _GLIBCXX_DLL when including
headers).
This allows using one single set of headers while linking against
either a DLL or a static library, just like on Unix platforms.
This matches how libc++ has been used in MinGW configurations for
years (by first building the DLL, then configuring a static-only
build and installing on top, overwriting the libc++ config file
with one for static linking) by multiple MinGW toolchains, making
the dllimport-less use the de-facto tested configuration in the wild.
This also allows building all of libc++ in one single CMake
configuration, instead of having to do two separate builds on top of
each other.
(Linking against a DLL without dllimport can break if e.g. templates
use inconsistent visibility attributes - in cases where it still
works when using explicit dllimport; such a case was fixed in
948dd664c3 / D99932. With this as the
default configuration, we can catch such issues in CI.)
Differential Revision: https://reviews.llvm.org/D125924
In clang-cl/MSVC environments, linking against a DLL C++ standard
library requires having dllimport attributes in the headers; this
has been used for detecting whether the tests link against a DLL,
by looking at the libc++ specific define
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS.
In mingw environments, thanks to slightly different code generation
and a couple linker tricks, it's possible to link against a DLL C++
standard library without dllimport attributes. Therefore, don't
rely on the libc++ specific header define for the detection.
Replace the detection with a runtime test.
Differential Revision: https://reviews.llvm.org/D125922
Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.
This is technically an ABI break, however I believe the actual potential
for breakage is very low.
rdar://90152242
Differential Revision: https://reviews.llvm.org/D125019
Instead of providing two different constructors for iterators that
support the debug mode, provide a single constructor but leave the
container parameter unused when the debug mode is not enabled.
This allows simplifying all the call sites to unconditionally pass
the container, which removes a bunch of duplication in the container's
implementation.
Note that this patch does add some complexity to std::span, however
that is only because std::span has the ability to use raw pointers
as iterators instead of __wrap_iter. In retrospect, I believe it was
a mistake to provide that capability, and so it will be removed in a
future patch, along with the complexity added by this patch.
Differential Revision: https://reviews.llvm.org/D126993
The `ranges.transform.pass.cpp` often times out on CI for AIX (32-bit and 64-bit)
only. Mark the test as `UNSUPPORTED` for `AIX` for now. It should be looked into in
the future.
Differential Revision: https://reviews.llvm.org/D127051
`string_view` is supported all the way back to C++03 as an extension in
`libc++`, and so many of the tests run in all standards modes for all vendors.
This is unlikely desired by other standard library vendors using our test suite.
So, disable the tests for vendors other than `libc++` in these older standards
modes.
Differential Revision: https://reviews.llvm.org/D126850
In D122982 I accidentally disabled the memmove optimization. This re-enables it and adds more cases where copy forwards to memmove.
Fixes https://github.com/llvm/llvm-project/issues/33687
Reviewed By: var-const, #libc, ldionne
Spies: pkasting, ayzhao, dcheng, xbolva00, libcxx-commits
Differential Revision: https://reviews.llvm.org/D124328
In 6423a9f0ec, I accidentally thought this was
getting tested, but these variables are unused. Just remove the lines instead of
leaving them commented out.
Differential Revision: https://reviews.llvm.org/D126901
Small typo fix(es) for struct definition of __optional_storage_base for
a reference type.
Reviewed By: #libc, jloser, philnik
Differential Revision: https://reviews.llvm.org/D126621
This removes the duplicated code from the dylib. Instead the dylib will
call the new functions in the header. Since this code is unneeded it's
removed from the unstable ABI.
Depends on D125704
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125761
Some test cases for `ends_with.ptr.pass` and `starts_with.ptr.pass` for
`string_view` are commented out, but work just fine. Uncomment them.
Differential Revision: https://reviews.llvm.org/D126849
Summary:
This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX.
Reviewed by: ldionne, MaskRay, libunwind, ibc++abi
Differential Revision: https://reviews.llvm.org/D126017
The functions to_chars and from_chars should offer 128-bit support. This
is the first step to implement 128-bit version of to_chars. Before
implementing 128-bit support the current code will be polished.
This moves the code from the dylib to the header in prepartion of
P2291 "Add Constexpr Modifiers to Functions to_chars and from_chars for
Integral Types in <charconv> Header"
Note some more cleanups will be done in follow-up commits
- Remove the _LIBCPP_AVAILABILITY_TO_CHARS from to_chars. With all code
in the header the availablilty macro is no longer needed. This
requires enabling the unit tests for additional platforms.
- The code in the dylib can switch to using the header implementation.
This allows removing the code duplicated in the header and the dylib.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D125704
Some tests in `string.view.comparison` are not enabled due to previous lack of
support for `constexpr std::string`. Now that it is implemented, we can enable
these tests.
Differential Revision: https://reviews.llvm.org/D126737
Formatting a string-literal had an off-by-one issue where the NUL
terminator became part of the formatted output.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D126665
The machine hosting these agents will be down
for maintenance June 2nd.
We (Linaro) will remove this once the agents are back online.
Differential Revision: https://reviews.llvm.org/D126688
P0798R8 "Monadic operations for std::optional" has been implemented, so
this LWG issue can be adopted.
During review it was discovered another paper bumped the macro. The
part affecting optional of this paper is done, the variant isn't. The
status page is updated to reflect the current state.
Implements
- LWG 3621 Remove feature-test macro __cpp_lib_monadic_optional
Updates status of
- P2231R1 Missing constexpr in std::optional and std::variant
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D125813
Clang 3.7 and below is not actively used or supported in the test suite now, so
remove the workaround in the test.
Differential Revision: https://reviews.llvm.org/D126603
Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.
Differential Revision: https://reviews.llvm.org/D126482
Add a warning and tweak the release note to explain that the deprecation
targets libc++, libc++abi and libuwnind as well.
Also, as a fly-by, ensure that our CI runs the legacy testing configuration
for libc++, libc++abi and libunwind. This doesn't matter too much since
it's deprecated, but we might as well test it properly.
Differential Revision: https://reviews.llvm.org/D126478
Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.
Differential Revision: https://reviews.llvm.org/D126496
While looking at D113413 I noticed that __log2i could perhaps be
improved to be both slightly smaller and faster.
projects/libcxx/benchmarks/sort.libcxx.out --benchmark_filter=BM_Sort_uint32_QuickSortAdversary*
suggests this is performance neutral, but it shaves a few bytes off the
benchmark binary, and even more off a Chromium build.
Differential revision: https://reviews.llvm.org/D125958
Start testing Apple backdeployment with older libunwinds, and stop
explicitly specifying the libunwind testing config, since it is
already selected correctly by default.
Differential Revision: https://reviews.llvm.org/D126470
Uncomment the tests to ensure `std::ranges::rbegin` and friends are indeed
customization points objects.
Differential Revision: https://reviews.llvm.org/D126325
Once we move off entirely from the legacy testing framework, this will
allow removing a bunch of code.
Differential Revision: https://reviews.llvm.org/D126303
This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.
Differential Revision: https://reviews.llvm.org/D125331
Abseil benchmarks suggest that the conditional checks result in faster code (4-5x)
as they are compiled into conditional move instructions (cmov on x86).
Reviewed By: #libc, philnik, Mordante
Spies: pengfei, Mordante, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125329
This fixes incorrect handling of non-moveable types, adding tests for this case.
See [issue 55346](https://github.com/llvm/llvm-project/issues/55346).
The current implementation is based on is_convertible, which is
[defined](https://timsong-cpp.github.io/cppwp/n4659/meta.rel#5) in terms of
validity of the following function:
```
To test() {
return declval<From>();
}
```
But this doesn't work if To and From are both some non-moveable type, which the
[definition](https://timsong-cpp.github.io/cppwp/n4659/conv#3) of implicit
conversions says should work due to guaranteed copy elision:
```
To to = E; // E has type From
```
It is this latter definition that is used in the
[definition](https://timsong-cpp.github.io/cppwp/n4659/function.objects#func.require-2)
of INVOKE<R>. Make __invokable_r use __is_core_convertible, which
captures the ability to use guaranteed copy elision, making the
definition correct for non-moveable types.
Fixesllvm/llvm-project#55346.
Reviewed By: #libc, philnik, EricWF
Spies: EricWF, jloser, ldionne, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D125300
This is essentially a revert of c7ad02009. Indeed, it seems that both
96dbdd75 and c7ad02009 were committed, but c7ad02009 seems to be only
an older version of 96dbdd75's tests.
We use `auto` in C++03, so we shouldn't say that we aren't.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D126165
All compilers that libc++ supports support `push_macro` and `pop_macro`. So let's remove it.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126073
`<type_traits>` is quite a large header, so I'll granularize it in a few steps.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D124755
We should not surface CMake-level options like LIBCXX_ENABLE_FILESYSTEM
to our users, since they don't know what it means. Instead, use a slightly
more general wording.
Also, add an error in <ios> to improve the quality of errors for people
trying to use <iostream> when localization is disabled.
Differential Revision: https://reviews.llvm.org/D125910
Also, add a CI job that tests this configuration. The exact configuration
is that we build a shared libc++ and merge objects for the ABI library
and the unwinder library into it.
Differential Revision: https://reviews.llvm.org/D125903
We require move semantics in C++03 anyways, so let's enable them for the containers.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123802
Summary:
fixed a return curr_symbol() for Russian in the libcxx/test/support/locale_helpers.h for AIX
Reviewers: David Tenty,Mark de Wever
Differential Revision: https://reviews.llvm.org/D125801
Use a specialized buffer wrapper to limit the number of insertions in the
buffer. After the limit has been reached the buffer only needs to count
the number of insertions to return the buffer size required to store the
entire output.
Depends on D110498
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D110499
This optimizes the __format_arg_store type to allow a more efficient
storage of the basic_format_args.
It stores the data in two arrays:
- A struct with the tag of the exposition only variant's type and the
offset of the element in the data array. Since this array only depends
on the type information it's calculated at compile time and can be
shared by different instances of this class.
- The arguments converted to the types used in the exposition only
variant of basic_format_arg. This means the packed data can be
directly copied to an element of this variant.
The new code uses rvalue reference arguments in preparation for P2418.
The handle class also has some changes to prepare for P2418. The real
changed for P2418 will be done separately, but these parts make it
easier to implement that paper.
Some parts of existing test code are removed since they were no longer
valid after the changes, but new tests have been added.
Implements parts of:
- P2418 Add support for std::generator-like types to std::format
Completes:
- LWG3473 Normative encouragement in non-normative note
Depends on D121138
Reviewed By: #libc, vitaut, Mordante
Differential Revision: https://reviews.llvm.org/D121514
This formatter isn't in the list of required formatters in
[format.formatter.spec]/2.2
For each charT, the string type specializations
template<> struct formatter<charT*, charT>;
template<> struct formatter<const charT*, charT>;
template<size_t N> struct formatter<const charT[N], charT>;
template<class traits, class Allocator>
struct formatter<basic_string<charT, traits, Allocator>, charT>;
template<class traits>
struct formatter<basic_string_view<charT, traits>, charT>;
Since remove_cvref_t<const charT[N]> is charT[N] the formatter is
required by
[format.functions]/25
Preconditions: formatter<remove_cvref_t<Ti>, charT> meets the
BasicFormatter requirements ([formatter.requirements]) for each Ti in
Args.
Depends on D120921
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D121138
The concept is based on P2286R2 Formatting Ranges. It will be used to
optimise the storage of __format_arg_store as required by LWG-3473.
Depends on D120916
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D120921
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)
Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library. If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.
The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.
(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)
This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.
Differential Revision: https://reviews.llvm.org/D125715
As mentionned in D97044, it is fine if users include <atomic> and then
include <stdatomic.h> -- we don't need to error out for that case.
Differential Revision: https://reviews.llvm.org/D125579
I think this notion of libc++abi's version was relevant a long time ago
on Apple platforms when we were using a Xcode project to build the library.
As part of moving Apple's build to CMake, D59489 made it possible to
specify the "ABI version" of libc++abi in use. However, it's not possible
to build libc++abi with that old ABI anymore and we don't need the ability
to link against that version from libc++ anymore.
Hence, we can clean this up and stop falsely pretending that libc++abi
has more than one ABI version.
Differential Revision: https://reviews.llvm.org/D125687
This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
`std::views::drops` and `std::views::join` have been implemented, but the tests
verifying the CPOs for them are still commented out. Uncomment the tests.
Differential Revision: https://reviews.llvm.org/D125618
Quite a few C++20 LWG issues/papers related to the One Ranges Proposal
were already effectively implemented (or contain semantic-only wording
changes that don't affect the implementation), mark them as such.
Differential Revision: https://reviews.llvm.org/D125065
This simplifies the string structs a bit more and the normal layout should not contain any undefined behaviour anymore. I don't think there is a way to achieve this in the alternate string mode without breaking the ABI.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D125496
For example, we used to trigger CI even for commits that touched a file
whose path contained 'cmake', even if it's not the root cmake directory.
Fix that.
Standalone builds have been deprecated and then removed for a while now.
Trying to use standalone builds leads to a fatal CMake error, so this
code is all dead. Remove it to clean things up.
Differential Revision: https://reviews.llvm.org/D125561
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
We add `--unwindlib=none` to `CMAKE_REQUIRED_FLAGS`
to make sure that builds with a yet-incomplete toolchain succeed,
to avoid linker failures about missing unwindlib.
When this option is added to `CMAKE_REQUIRED_FLAGS`, it gets added to
both compile and link commands in CMake compile tests. If
`--unwindlib=none` is included in compilation commands, it causes
warnings about unused arguments, as the flag only is relevant for
linking.
Due to the warnings in CMake tests, the later CMake test for the
`-Werror` option failed (as the tested `-Werror` option caused the
preexisting warning due to unused `--unwindlib=none` to become a
hard error). Therefore, most CI configurations that build with
`LIBCXX_ENABLE_WERROR` didn't actually end up enabling `-Werror`
after all.
When looking at the CI build log of recent CI builds, they do
end up printing:
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG
-- Performing Test LIBCXX_SUPPORTS_WERROR_FLAG - Failed
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG
-- Performing Test LIBCXX_SUPPORTS_WX_FLAG - Failed
Thus while the configurations are meant to error out on warnings,
they actually haven't done that, due to the interaction of these
options.
To fix this, remove the individual cases of adding `--unwindlib=none`
into `CMAKE_REQUIRED_FLAGS` in libcxx and libunwind.
`runtimes/CMakeLists.txt` still adds `--unwindlib=none` if needed, but
not otherwise. (The same issue with enabling `-Werror` does remain
if `--unwindlib=none` strictly is needed though - that can be fixed
separately afterwards.)
These individual cases in libunwind and libcxx were added while
standalone builds of the runtimes still were supported - but no longer
are necessary now.
Differential Revision: https://reviews.llvm.org/D124375
I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.
Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd30, but I don't really see
any discussion around this detail there.
Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:
```
In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4 bytes) [-Watomic-alignment]
return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
^
4 warnings generated.
```
Differential Revision: https://reviews.llvm.org/D124519
This isn't a configuration that we unfortunately can add to
the CI practically at the moment, but I do run the tests
sporadically offline in this configuration.
Differential Revision: https://reviews.llvm.org/D124993
After feedback from D122861, do the same thing with some of the other headers. Try to move the
headers so they have a similar style and way of doing things.
Reviewed By: ldionne, daltenty
Differential Revision: https://reviews.llvm.org/D124227
This only adds the customization point object (which isn't pipeable),
the view itself has already been implemented previously.
Differential Revision: https://reviews.llvm.org/D124978
[libcxx] Reject month 0 in get_date/__get_month
This fixes#47663.
Months in dates should be >= 1 and <= 12.
We parse up to two digits then minus one, because
we want to store this as "months since January"
(0-11).
However we didn't check that the result of that
was not -1. For example if you had (MM/DD/YYYY)
00/21/2022.
Added tests for:
* Failing if month is 0
* Failing if month is 13
* Allowing a leading zero in month e.g. "01"
Note that libc++ and libstdc++ return different
values on parsing failure, and MSVC STL returns
end of stream instead.
Handle the first two by checking for defines, MSVC STL
expects these tests to fail for other reasons already:
https://github.com/microsoft/STL/blob/main/tests/libcxx/expected_results.txt#L372
so not handling that case here.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D124175
On targets without unistd.h or sys/wait.h (such as bare metal targets)
any test that uses check_assertion.h will fail, so add
REQUIRES: has-unix-headers to them and autodetect whether we have
these headers or not.
These tests currently have unsupported on windows, but that's exactly
because windows doesn't have these headers so we can remove the
specific check for windows.
Differential Revision: https://reviews.llvm.org/D124623
Adding a mingw based config is easy in the current CI environment
(where we can just choose the different target by calling
`i686-w64-mingw32-clang`), while adding a clang-cl based config would
require setting up different environment variables pointing to the
i386 library directory.
Just adding one config (DLL) instead of exhaustively testing both
(DLL and static) as very few tests would differ in practice, to keep
the CI load reasonable.
Differential Revision: https://reviews.llvm.org/D124991
This test only fails on x86_64 clang-cl, not for i386.
(The root cause is still not explored, thus the FIXME is still
relevant.)
Differential Revision: https://reviews.llvm.org/D124994
All current Windows architectures (i386, x86_64, arm, arm64) get
the full_size() behaviour here. x86_64 (the only one tested in CI
currently) is handled by the first ifdef at the top, but handle
Windows in general on all other architectures later.
Differential Revision: https://reviews.llvm.org/D124989
There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.
Reviewed By: #libc, Mordante, martong, ldionne
Differential Revision: https://reviews.llvm.org/D124708
Several helper functions specify preconditions as comments, but we never
check them. I ran across a bug report (without a reproducer) in this code,
and I thought that having these assertions in place would make it easier
to troubleshoot.
Differential Revision: https://reviews.llvm.org/D124477
Reorganize the test and simplify the #ifdefs. Fix a typo in __powerpc64__
as a fly-by, and also add a test for the unstable ABI.
Differential Revision: https://reviews.llvm.org/D124403
Replace all the instances of `_LIBCPP_INLINE_VISIBILITY` with `_LIBCPP_HIDE_FROM_ABI` and `_VSTD` with `std`.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D124662
We are considering to make -fsanitize-memory-param-retval enabled by default so probably this patch is unnneded.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D123979
The GCC failures were partly fixed in D124103.
The format functions tests are fixed on GCC but they require a huge
amount of RAM (>10 GB). This fails with parallel testing in the CI. It
can be solved by splitting the test, but GCC-12 will be released shortly
and might fix the memory usage in these tests. Therefore these tests
remain disabled.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D124335
Detected on many lld tests with -fsanitize-memory-use-after-dtor.
Also https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-fast after D122869 will report a lot of them.
Threads may outlive static variables. Even if ~__thread_specific_ptr() does nothing, lifetime of members ends with ~ and accessing the value is UB https://eel.is/c++draft/basic.life#1
```
==9214==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x557e1cec4539 in __libcpp_tls_set ../include/c++/v1/__threading_support:428:12
#1 0x557e1cec4539 in set_pointer ../include/c++/v1/thread:196:5
#2 0x557e1cec4539 in void* std::__msan::__thread_proxy<
std::__msan::tuple<...>, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()> >(void*) ../include/c++/v1/thread:285:27
Memory was marked as uninitialized
#0 0x557e10a0759d in __sanitizer_dtor_callback compiler-rt/lib/msan/msan_interceptors.cpp:940:5
#1 0x557e1d8c478d in std::__msan::__thread_specific_ptr<std::__msan::__thread_struct>::~__thread_specific_ptr() libcxx/include/thread:188:1
#2 0x557e10a07dc0 in MSanCxaAtExitWrapper(void*) compiler-rt/lib/msan/msan_interceptors.cpp:1151:3
```
The test needs D123979 or -fsanitize-memory-param-retval enabled by default.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122864
from libcxx/test/std/input.output/string.streams/stringbuf/stringbuf.virtuals/
[NFC] As part of using inclusive language within the llvm project, this
patch rewords comments to remove sanity check.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D124391
On x86 long double is 80 bit with padding, which produces
uninitialized bits in the result.
This will trigger errors with -fsanitize-memory-param-retval.
Can be triggered with D123979.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D123980
- add zip_view and views::zip for C++23
- added unit tests
- implemented section 5.6 (zip) in P2321R2
I used clang-format to format the files but they look nothing like the rest of the code base. Manually indenting each line to match the styles sounds like an impossible task. Is there any clang-format file which can format it reasonable similar to the rest of the code base so that I can manually format the rest lines that look weird?
Reviewed By: ldionne, #libc, philnik, var-const
Spies: Mordante, philnik, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D122806
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
D123182 fixes a bug in Clang's overload resolution. After it landed it
was discovered `basic_format_arg`'s constructors contains this bug. This
fixes the bug in libc++, unblocking D123182.
The code has been tested in combination with D123182.
Reviewed By: royjacobson, #libc
Differential Revision: https://reviews.llvm.org/D124103
`vector<bool>::const_reference` and `vector<bool>::const_iterator::reference` should be the same type.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123851
Summary:
1. there are 23 test cases which do not run because of locale fileset not install, after the locale installed, these test cases will be run and fail. "LIBCXX-AIX-FIXME" on the 23 test cases which remain to be investigated on AIX.
2.after installed the locale fileset ,
the test case
libcxx/test/std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp pass
remove XFAIL: LIBCXX-AIX-FIXME from the file
Reviewers: David Tenty
Differential Revision: https://reviews.llvm.org/D124174
This makes the code a bit simpler and (I think) removes the undefined behaviour from the normal string layout.
Reviewed By: ldionne, Mordante, #libc
Spies: labath, dblaikie, JDevlieghere, krytarowski, jgorbe, jingham, saugustine, arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123580
- added views::join adaptor object
- added test for the adaptor object
- fixed some join_view's tests. e.g iter_swap test
- added some negative tests for join_view to test that operations do not exist when constraints aren't met
- added tests that locks down issues that were already addressed in previous change
- LWG3500 `join_view::iterator::operator->()` is bogus
- LWG3313 `join_view::iterator::operator--` is incorrectly constrained
- LWG3517 `join_view::iterator`'s `iter_swap` is underconstrained
- P2328R1 join_view should join all views of ranges
- fixed some issues in join_view and added tests
- LWG3535 `join_view::iterator::iterator_category` and `::iterator_concept` lie
- LWG3474 Nesting ``join_views`` is broken because of CTAD
- added tests for an LWG issue that isn't resolved in the standard yet, but the previous code has workaround.
- LWG3569 Inner iterator not default_initializable
Reviewed By: #libc, var-const
Spies: var-const, libcxx-commits
Differential Revision: https://reviews.llvm.org/D123466
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.
This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.
We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.
In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.
The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.
This is a re-commit of
fc30901096,
a571f82a50,
64c045e25b, and
de6ddaeef3,
and reverts aa643f455a.
This change also includes a workaround for users using libc++ 3.1 and
earlier (!!), as apparently happens on AIX, where std::move sometimes
returns by value.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D123345
Revert "Fixup D123950 to address revert of D123345"
This reverts commit aa643f455a.
functions are not treated as [[nodiscard]].
The compiler might choose to treat them as [[nodiscard]] without the
involvement of libc++ if we allow it to recognize them as builtins.
This makes it a little easier to reuse the libc++ tests for another
std::lib (specifically libstdc++).
The regex_error::what() strings are different in other
implementations, so should be tested with LIBCPP_ASSERT so that those
checks are skipped for other implementations.
The value of ECMAScript constant is non-zero in other implementations,
and conditionally for libc++, so adjust the preprocessor condition for
that too.
Reviewed By: ldionne, #libc, philnik, Mordante
Spies: Mordante, philnik, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122574
Note that this class was called just `split_view` in the original One
Ranges Proposal and was renamed to `lazy_split_view` by
[P2210](https://wg21.link/p2210).
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D107500
When we build the library with the stable ABI, we need to include some
functions in the dylib that were made inline in later versions of the
library (to avoid breaking code that might be relying on those symbols).
However, those methods were made non-inline whenever we'd be building
the library, which means that all translation units would end up using
the old out-of-line definition of these methods, as opposed to the new
inlined version. This patch makes it so that only the translation units
that actually define the out-of-line methods use the old definition,
opening up potential optimization opportunities in other translation
units.
This should solve some of the issues encountered in D65667.
Differential Revision: https://reviews.llvm.org/D123519
In the C++20 Standard time is no longer section under utilities, but
became its own chapter. This moves the time tests accordingly so their
location matches the current Standard.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122745
If a single test has been running for more than 20 minutes on a CI node,
something is wrong and it should time-out instead of running until the
node potentially times out itself.
Differential Revision: https://reviews.llvm.org/D114896
The Android platform does not have ndk-version.h, but it will always
have up-to-date libc headers, so it does not need any compatibility
code intended for past versions of NDK_MAJOR. If ndk-version.h is missing,
assume NDK_MAJOR is (conceptually) infinite
Bug: https://buganizer.corp.google.com/issues/222341313
Test: None
On non-Windows platforms, get_temp_file_name() uses `mkstemp()`,
which picks a unique name and creates a file atomically. The
Windows implementation uses `_mktemp_s()`, which doesn't create the
file. The documentation of `_mktemp_s()` also says that by design,
the function uses the same pattern within a process, as long as that
file doesn't exist.
Thus previously, two consecutive calls to `get_temp_file_name()`
on Windows returned the same file name.
Try to create the suggested temp file with `_O_EXCL` (marking the
file name as already used for future calls to `_mktemp_s`) and retry
if we weren't able to exclusively create the file.
This fixes the test failures on Windows observed in D122257.
Differential Revision: https://reviews.llvm.org/D122612
This supersedes and incoroporates content from both D108906 and D54966,
and also some original content.
Co-Authored-by: Marshall Clow <mclow.lists@gmail.com>
Co-Authored-by: Gonzalo Brito Gadeschi
Differential Revision: https://reviews.llvm.org/D118938
Use a specialized "buffer" to count the number of insertions instead of
using a `string` as storage type.
Depends on D110497.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110498
Instead of writing every character directly into the container by using
a `back_insert_iterator` the data is buffered in an `array`. This buffer
is then inserted to the container by calling its `insert` member function.
Since there's no guarantee every container's `insert` behaves properly
containers need to opt-in to this behaviour. The appropriate standard
containers opt-in to this behaviour.
This change improves the performance of the format functions that use a
`back_insert_iterator`.
Depends on D110495
Reviewed By: ldionne, vitaut, #libc
Differential Revision: https://reviews.llvm.org/D110497
This is to simplify the changes made in D122780. This diff was generated using the command:
```
clang-format include/__algorithm/sort.h -i
```
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122858
This patch addresses a clash with the PS register from Xtensa
defined in the <specreg.h> header file, which is commonly included in
OS implementation.
Issue identified while building libc++ port for Apache NuttX, targeting
Xtensa-based chips (e.g. Espressif's ESP32).
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Differential Revision: https://reviews.llvm.org/D122479
This change is done to see whether all platforms have a CI with the
Japanese locale installed.
This wires in the locale in the tests and uses it in one test. This is
a preparation for the tests of the chrono formatters.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122738
Adds a `__get_container` member as suggested by @Quuxplusone in D110497.
Includes s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/.
Reviewed By: Quuxplusone, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110573
Before implementing P2216's format-string adjust the unit tests.
After P2216 the format* functions require a compile-time string literal.
This changes prepares the tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D122534
`__is_callable` is required to ensure that the classic algorithms are only called with functions or functors. I also begin to granularize `<type_traits>`.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D123114
We are introducing branchless variants for sort3, sort4 and sort5.
These sorting functions have been generated using Reinforcement
Learning and aim to replace __sort3, __sort4 and __sort5 variants
for integral types.
The libc++ benchmarks were run on isolated machines for Skylake, ARM and
AMD architectures and achieve statistically significant improvement in
sorting random integers on test cases from sort1 to sort262144 for
uint32 and uint64.
A full performance overview for Intel Skylake, AMD and Arm can be
found here: https://bit.ly/3AtesYf
Reviewed By: ldionne, #libc, philnik
Spies: daniel.mankowitz, mgrang, Quuxplusone, andreamichi, philnik, libcxx-commits, nilayvaish, kristof.beyls
Differential Revision: https://reviews.llvm.org/D118029
Introduce _LIBCPP_ASSERTIONS_DISABLE_ASSUME which makes _LIBCPP_ASSERT
not call __builtin_assume when _LIBCPP_ENABLE_ASSERTIONS == 0.
Calling __builtin_assume was introduced in D122397.
__builtin_assume is generally supposed to improve optimizations, but can
cause regressions when LLVM has trouble handling the calls to
`llvm.assume()` (see comments in D122397).
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D123175
There are `constexpr` versions for the different `__invoke` functions, which seem to be identical other than begin `constexpr` since C++11 instead of being `constexpr` since C++20.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D123003
There are no such markings left - all of them have been fixed or
analyzed.
This closes llvm.org/PR32730 (github issue #32077).
Differential Revision: https://reviews.llvm.org/D123145
The is a followup of D116965 to split the calendar header. This is a
preparation to add the formatters for the chrono header.
The code is only moved no other changes have been made.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D122995
This patch implements P0674R1, i.e. support for arrays in std::make_shared
and std::allocate_shared.
Co-authored-by: Zoe Carver <z.zoelec2@gmail.com>
Differential Revision: https://reviews.llvm.org/D62641
On Windows, like on macOS and FreeBSD, widening char(-5) in the
"C" locale succeeds and produces L'\u00fb'.
Switch widen_many to test \xfb instead of \x85; the mingw
version of btowc widens \x85 in the "C" locale into
\u2026 (which is the corresponding character according to the
Windows-1252 codepage), while Microsoft CRT's btowc widens it
into \u0085 (just like macOS and FreeBSD). Switch this to test \xfb
which is the character tested by the widen_1 test (as `char(-5)`),
which gets handled the same by all Windows implementations of btowc.
Differential Revision: https://reviews.llvm.org/D121003
[libc++] add global variable template std::views::empty
Note it is neither a range adaptor, nor a CPO. It is simplify a global variable template.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D122996
This iterator is used to test code that only needs to satisfy the
output_iterator concept. Follow-up changes will use this iterator in
older language Standards.
Reviewed By: ldionne, #libc, philnik, var-const
Differential Revision: https://reviews.llvm.org/D122072
Instead of using `.fail.cpp` tests, use `.verify.cpp` to check for the
exact reason of the failure. In the case of deduction guides, use SFINAE
based tests instead since that is our preferred way of testing those.
Finally, ensure that we actually run the test in `iter_alloc_deduction.pass.cpp`,
since we were not running anything before.
Differential Revision: https://reviews.llvm.org/D123055
Since a8d15a9266 / D110975, this is
the default, even if winpthread headers are available, so we don't
need to cargo cult setting this option in all builds.
Differential Revision: https://reviews.llvm.org/D122717
Note that `generate_assertion_tests.py` will be renamed to
`generate_header_tests.py` separately to facilitate change tracking.
Differential Revision: https://reviews.llvm.org/D123000
The pointer.volatile.pass.cpp test was already marked as XFAIL for
mingw-dll (for reasons explained in the comment above it).
The same issue also appears in clang-cl-dll when built with newer
CMake versions. (It didn't appear with older versions of CMake, as
CMake built the library with the clang-cl flag `-std:c++latest` when
we've requested C++ 20 - which practically built it in c++2b mode with
current clang versions. With current versions of CMake, it passes
`-std:c++20` instead.)
As it succeeds/fails dependent on factors we don't
directly control, mark it as UNSUPPORTED instead of XFAIL.
Differential Revision: https://reviews.llvm.org/D122718
Note of the functions was marked as _LIBCPP_HIDE_FROM_ABI.
Did some minor formatting fixes to keep consistency. To keep it easy to
review not all odd formatting has been fixed.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122834
The alternative outputs of std::put_time and std::strftime are the
easiest to test with the Japanese locale. This is a preparation for the
tests of the chrono formatters.
Note since it takes a while before the Docker file changes propagate to
the build nodes the verification of the locale is done in a separate
patch.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122736
Reduced the details of the non-chrono formatting information. This has
been shipped and these details part of P0645 which is still documented.
Removing this information keeps the information up-to-date.
Adds the formatters required for the types chrono namespace.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D122735
It seems to have been added back in 761e42fa3d for Clang to use it,
however it seems to have never been used for that purpose, so it is
probably fine to remove it.
Differential Revision: https://reviews.llvm.org/D122330
For some reason, we've been going without a MSAN CI job, even though
even run-buildbot defined a generic-msan job. This must have been an
oversight that went unnoticed. Thanks to @EricWF for the catch.
Differential Revision: https://reviews.llvm.org/D120851
This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.
It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.
Differential Revision: https://reviews.llvm.org/D122506
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
Since we expect the condition to be true most of the time, we might
as well tell the compiler. And when assertions are disabled, we
might as well tell the compiler that it's allowed to assume that
the condition holds.
Differential Revision: https://reviews.llvm.org/D122397
This means that re-running with llvm-lit in that configuration will
work as expected. This also enables assertions in libc++abi in the
Generic-assertions CI job, which was disabled previously.
Differential Revision: https://reviews.llvm.org/D122597
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.
The changes from the One Ranges Proposal amount to adding:
- a constructor that takes a `default_sentinel_t` and is equivalent to
the default constructor;
- an `operator==` that compares the iterator to `default_sentinel_t`.
The original proposal defined two overloads for `operator==` (different
argument order) as well as `operator!=`. This has been removed by
[P1614](https://wg21.link/p1614).
Differential Revision: https://reviews.llvm.org/D119620
I'm trying to get libc++ to the point of being able to run clang-tidy. This is a PR to see if clang-tidy is happy with all the CI configs.
Reviewed By: Quuxplusone, ldionne, #libc
Spies: mgorny, aheejin, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D117174
We shouldn't be calling `distance` 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 `distance` in particular.
Differential Revision: https://reviews.llvm.org/D119685
This change will make it possible to track exported symbols in more
configurations, notably the Apple system one, where we disable incomplete
features and the debug mode. Also, as a fly-by fix, shorten the name for
whether new is in libc++ or not.
Differential Revision: https://reviews.llvm.org/D119764
Also, fix the actual code so that the test would pass if we fixed the
issue that the method is instantiated in the dylib, and hence the debug
assertion will never fire except if the debug mode is enabled when the
dylib is being compiled.
Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.
I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.
Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.
Differential Revision: https://reviews.llvm.org/D119561
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
As suggested in D117966.
These conditional noexcepts are *permitted* by the Standard (as long
as there were no mistakes in them, I guess); but not *mandated*.
The Standard doesn't put any noexcept-specifications on these member functions.
The same logic would apply to `transform_view::iterator::operator*`
and `transform_view::iterator::operator[]`, but the Standard mandates
conditional noexcept on `iter_move(transform_view::iterator)`, and
I think it doesn't make much sense to say "moving from this iterator
is conditionally noexcept but not-moving from it is noexcept(false),"
so I'm leaving transform_view alone for now.
Differential Revision: https://reviews.llvm.org/D119374
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Differential Revision: https://reviews.llvm.org/D118736
The test would trigger -Wtautological-compare. I think that the little
we gain from comparing addresses isn't worth the added complexity to
work around the warning.
Summary:
The pragma priority guarded for AIX in locale.cpp is no longer useful and is ignored by the current AIX build compilers. This patch removes it from the source.
Reviewed by: ldionne, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D119765
This makes the GCC output even cleaner!
Reviewed By: ldionne, #libc
Spies: mstorsjo, Quuxplusone, Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D119295
We added one for libc++ recently, and this patch adds one for libc++abi.
Also, as a fly-by fix, include older libunwind dylibs in the testing of
libc++ and libc++abi, which fixes some issues related to running
back-deployment tests on newer systems.
Differential Revision: https://reviews.llvm.org/D119466
This test feeds in the expected utf8 form of weekdays in various
languages, trying to match what libc++ has gathered internally
from `strftime()`. On glibc, the ru_RU.UTF-8 representation of the
tested weekday is spelled with upper case, while the existing
test reference is lower case.
Differential Revision: https://reviews.llvm.org/D118237
Also opt in to testing the hexadecimal float formatting for glibc; glibc
does matches the current test references there.
Differential Revision: https://reviews.llvm.org/D118238
This fixes warnings about implicitly declared `_umul128` and
`__shiftright128` when building for x86_64 with clang-cl.
Use `_MSC_VER` instead of `_LIBCPP_COMPILER_MSVC` for enabling MSVC
specific code; `_MSC_VER` is defined both in clang-cl and MSVC,
while `_LIBCPP_COMPILER_MSVC` only is defined if building with the
actual MSVC compiler.
Include `ryu.h` at the head of `d2s_intrinsics.h`, as it uses
the `_LIBCPP_64_BIT` define, which is defined in `ryu.h`.
Now the Ryu files build without warnings with clang-cl for i386,
x86_64, arm and aarch64.
Differential Revision: https://reviews.llvm.org/D119647
`<filesystem>` header has been around for a while now, so we can safely remove
`<experimental/filesystem>` header. `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM`
suggests we were going to remove `<experimental/filesystem>` in llvm 11 release,
but we never did. So, remove the experimental header now, its associated tests,
and the `_LIBCPP_DEPRECATED_EXPERIMENTAL_FILESYSTEM` macro.
Differential Revision: https://reviews.llvm.org/D119603
Despite the comment saying `[[no_unique_address]]` on the `__base_` data member
makes clang crash, this does not seem to be true on CI. So, mark `__base_` with
`_LIBCPP_NO_UNIQUE_ADDRESS`.
Differential Revision: https://reviews.llvm.org/D119208
- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
used;
- add a missing include.
Reviewed By: philnik
Differential Revision: https://reviews.llvm.org/D119214
This reverts commit 2722ac65. As explained in D115906, this was actually
unnecessary and it broke the external threading configuration.
Differential Revision: https://reviews.llvm.org/D119484
This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.
The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.
Differential Revision: https://reviews.llvm.org/D119410
`ranges_swap_ranges.h` includes `<type_traits>` but does not use anything from
it. So, remove the include.
Differential Revision: https://reviews.llvm.org/D119491
This avoids using an libc++ internal macro in our tests. This version
doesn't depend on the internal macro but redefines it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119460
`{back,front}_insert_iterator` and `ostream{,buf}_iterator` effectively
fully implement the One Ranges Proposal already, so mark them as done:
- the change to `difference_type` was made by D103273;
- default constructors and the associated default member initializers
were removed by wg21.link/P2325 (implemented by D102468).
Also fix a stale template signature in the `<iterator>` synopsis.
We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.
Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.
Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.
Differential Revision: https://reviews.llvm.org/D119351
In libc++, checking specific `_LIBCPP_DEBUG_LEVEL` levels is used everywhere except in `comp_ref_type.h`. `_LIBCPP_DEBUG` is meant as a user-facing option, and internally libc++ should be checking the value of `_LIBCPP_DEBUG_LEVEL`.
The definition of `std::__debug_less` doesn't need to be hidden behind the macro, we can unconditionally expose it. It will be unused by `__comp_ref_type` unless debug mode is enabled.
This was suggested in D118940.
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118950
b07b5bd727 adds a use of `__comp_ref_type.h` to `std::min`. When libc++ is built with `-D_LIBCPP_DEBUG=0`, this enables `std::__debug_less`, which is only marked constexpr after c++17.
`std::min` itself is marked as being `constexpr` as of c++14, so by extension, `std::__debug_less` should also be marked `constexpr` for the same versions so that `std::min` can use it. This change lowers the guard from `> 17` to `> 11`.
Reproducer in godbolt: https://godbolt.org/z/ans3TGsj8
```
constexpr int x() { return std::min<int>({1, 2, 3, 4}); }
static_assert(x() == 1);
```
Reviewed By: #libc, philnik, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D118940
Glibc adds a +-sign for NaN-values when showpos fmtflags are set.
[tab:ios.fmtflags]
showpos generates a + sign in non-negative generated numeric output
Since NaNs aren't negative this behaviour seems correct. Enable the test
for glibc and add ifdefs to make sure the existing tests still pass.
This was noticed while working on D118971.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119260
Nikolas Klauser