Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
We can define some of these aliases without having to include the system
<stddef.h> and there doesn't seem to be much of a reason we shouldn't do
it this way.
`<string>` doesn't seem to be required at all and `flat_map` doesn't
support `vector<bool>`, so we can include just `vector<T>`. This cuts
the include time in half on my system.
This PR fixes the `ThrowingT` class, which currently fails to raise
exceptions after a specified number of copy construction operations. The
class is intended to throw in a controlled manner based on a specified
counter value `throw_after`. However, its current implementation of the
copy constructor fails to achieve this goal.
The problem arises because the copy constructor does not initialize the
`throw_after_n_` member, leaving `throw_after_n_` to default to `nullptr`
as defined by the in-class initializer. As a result, its copy constructor
always checks against `nullptr`, causing an immediate exception rather
than throwing after the specified number `throw_after` of uses. The fix
is straightforward: simply initialize the `throw_after_n_` member in the
member initializer list.
This issue was previously uncovered because all exception tests for
`std::vector` in `exceptions.pass.cpp` used a `throw_after` value of 1,
which coincidentally aligned with the class's behavior.
This patch fixes warnings and errors that come up when running the
benchmarks as part of the test suite. It also adds the necessary Lit
annotations to make it pass in various configurations and increases the
portability of the benchmarks.
Summary:
The GPU runs these tests using the files built from the `libc` project.
These will be placed in `include/<triple>` and `lib/<triple>`. We use
the `amdhsa-loader` and `nvptx-loader` tools, which are also provided by
`libc`. These launch a kernel called `_start` which calls `main` so we
can pretend like GPU programs are normal terminal applications.
We force serial exeuction here, because `llvm-lit` runs way too many
processes in parallel, which has a bad habit of making the GPU drivers
hang or run out of resources. This allows the compilation to be run in
parallel while the jobs themselves are serialized via a file lock.
In the future this can likely be refined to accept user specified
architectures, or better handle including the root directory by exposing
that instead of just `include/<triple>/c++/v1/`.
This currently fails ~1% of the tests on AMDGPU and ~3% of the tests on
NVPTX. This will hopefully be reduced further, and later patches can
XFAIL a lot of them once it's down to a reasonable number.
Future support will likely want to allow passing in a custom
architecture instead of simply relying on `-mcpu=native`.
Not all the code path has been exercised by the tests for
`flat_map::emplace_hint`
Adding more test coverage.
At the same time, adding more test cases for `flat_map::emplace`
We were using macros instead of functions, leading to the inability to
properly qualify calls to those symbols inside <locale>. This is also a
step towards making the locale API modules-correct.
As a drive-by, remove unused functor inside the unordered_set benchmark.
That benchmark still isn't very exhaustive, but that can be addressed
separately.
This PR deprecates `<ccomplex>`, `<cstdbool>`, `<ctgmath>`, and
`<ciso646>` in C++17 and "removes" them in C++20 by special deprecation
warnings.
`<cstdalign>` is previously missing. This PR also tries to add them, and
then deprecates and "removes" `<cstdalign>`.
Papers:
- https://wg21.link/P0063R3
- https://wg21.link/P0619R4Closes#99985.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Fixes#109858.
The changes in #81379 broke some 3rd party library code that expected
usability of `std::complex<NonFloatingPoint>`. Although such code isn't
portable per [complex.numbers.general]/2, it might be better to make
these additional overloads not to interfere overload resolution too
much.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Making it meet the requirements for allocator since C++11. Fixes
#113609.
This PR doesn't make it meet the C++03 allocator requirements, because
that would make the type too verbose and libc++ has backported many
C++11 features to the C++03 mode.
Drive-by: Removes the `TEST_CONSTEXPR_CXX14` on `allocate`/`dealocate`
which is never in effect (and causes IFNDR-ness before C++23), since
these functions modify the namespace-scoped variable `allocated_`.
Added exception guard to the `vector(n, x, a)` constructor to enhance
exception safety. This change ensures that the `vector(n, x, a)`
constructor is consistent with other constructors, such as `vector(n)`,
`vector(n, x)`, `vector(n, a)`, in terms of exception safety.
This implements a warning that's similar to what GCC does in that
context: both memcpy and memset require their first and second operand
to be trivially copyable, let's warn if that's not the case.
Around half of the tests are based on the tests Arthur O'Dwyer's
original implementation of std::flat_map, with modifications and
removals.
partially implement #105190
MSVC STL's test suite is a bit nervous about replacing non-macro-defined
identifiers with `0` (see also
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4668?view=msvc-170).
On MSVC (and MS-compatible mode of other compilers), `long double` has
the same format (IEEE-754 binary64) as `double`, so it should be OK to
define `TEST_LONG_DOUBLE_IS_DOUBLE` when `_MSC_VER` is defined. Such
detection should be performed first.
In C++20 mode, `__cpp_lib_optional` and `__cpp_lib_variant` should be
`202106L` due to DR P2231R1.
In C++26 mode, `__cpp_lib_variant` should be bumped to `202306L` due to
P2637R3.
- Clang 16/17 shouldn't get this bumping (as member `visit` requires
explicit object parameters), but it's very tricky to make the bumping
conditionally enabled. I _hope_ unconditionally bumping in C++26 will be
OK for LLVM 20 when the support for Clang 17 is dropped.
Related PRs:
- https://reviews.llvm.org/D102119
- #83335
- #76447
MSVC doesn't understand `-Wno-psabi`, which was introduced here by
@ldionne in #106077.
Using `ADDITIONAL_COMPILE_FLAGS(gcc-style-warnings)` (implemented by
#75317) avoids passing this to MSVC.
The std::prev function appeared to work on non Cpp17BidirectionalIterators, however it
behaved strangely by being the identity function. That was extremely misleading and
potentially dangerous, since several recent iterators that are C++20 bidirectional_iterators
don't satisfy the Cpp17BidirectionalIterator named requirement. For example:
auto zv = std::views::zip(vec1, vec2);
auto it = zv.begin() + 5;
auto it2 = std::prev(it); // "it2" will be the same as "it", instead of the previous one
Here, zip_view::iterator is a c++20 random_access_iterator, but it only satisfies the
Cpp17InputIterator named requirement because its reference type is a proxy type. Hence
`std::prev` would silently accept that iterator but it would do a no-op instead of going
to the previous position.
This patch changes `std::prev(it)` to produce an error at compile-time when instantiated
with a type that is not a Cpp17BidirectionalIterator.
Fixes#109456
Since we don't generate a full dependency graph of headers, we can
greatly simplify the script that parses the result of --trace-includes.
At the same time, we also unify the mechanism for detecting whether a
header is a public/C compat/internal/etc header with the existing
mechanism in header_information.py.
As a drive-by this fixes the headers_in_modulemap.sh.py test which had
been disabled by mistake because it used its own way of determining
the list of libc++ headers. By consistently using header_information.py
to get that information, problems like this shouldn't happen anymore.
This should also unblock #110303, which was blocked because of
a brittle implementation of the transitive includes check which broke
when the repository was cloned at a path like /path/__something/more.
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
These headers are not doing anything beyond the system or compiler
provided equivalent headers, so there's no real reason to keep them
around. Reducing the number of C headers we provide in libc++ simplifies
our header layering and reduces the potential for confusion when headers
are layered incorrectly.
`reverse_iterator` supports either c++20 `bidirectional_iterator` or
`Cpp17BidirectionalIterator `
http://eel.is/c++draft/reverse.iter.requirements
The current `reverse_iterator` uses `std::prev` in its `operator->`,
which only supports the `Cpp17BidirectionalIterator` properly.
If the underlying iterator is c++20 `bidirectional_iterator` but does
not satisfy the named requirement `Cpp17BidirectionalIterator`,
(examples are `zip_view::iterator`, `flat_map::iterator`), the current
`std::prev` silently compiles but does a no-op and returns the same
iterator back. So `reverse_iterator::operator->` will silently give a
wrong answer.
Even if we fix the behaviour of `std::prev`, at best, we could fail to
compile the code. But this is not ok, because we need to support this
kind of iterators in `reverse_iterator`.
The solution is simply to not use `std::prev`.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Currently, libc++'s `bitset`, `forward_list`, and `list` have
non-conforming member typedef name `base`. The typedef is private, but
can cause ambiguity in name lookup.
Some other classes in libc++ that are either implementation details or
not precisely specified by the standard also have member typdef `base`.
I think this can still be conforming.
Follows up #80706 and #111127.
Instead of placing artifacts for testing the runtimes at <build>/test,
place those artifacts at <build>/<project>/test. This prevents
cluttering the build directory with the runtimes' test artifacts for
everyone else.
As a drive-by, remove LIBCXX_BINARY_INCLUDE_DIR which wasn't used
anymore.
Make __libcpp_verbose_abort() noexcept (it is already noreturn), to
match std::terminate(). Clang's function effect analysis can use this to
ignore such functions as being beyond its scope. (See
https://github.com/llvm/llvm-project/pull/99656).
The changes are nearly pure simplifications, so I think it's OK to do
them together in the same PR.
Actual test coverages were already added in commit ad41d1e26b12
(https://reviews.llvm.org/D141216). Thanks to Casey Carter!
Fixes#104975
Towards #105200
`overload_compare_iterator` only supports operations required for
forward iterators. On the other hand, it is used for output iterators of
uninitialized memory algorithms, which requires it to be forward
iterator.
As a result, `overload_compare_iterator<I>::iterator_category` should
always be `std::forward_iterator_tag` if we don't extend its ability.
The correct `iterator_category` can prevent standard library
implementations like MSVC STL attempting random access operations on
`overload_compare_iterator`.
Fixes#74756.
Previously, SFINAE constraints and exception specification propagation
were missing in the return type of libc++'s `std::mem_fn`. The
requirements on expression-equivalence (or even plain "equivalent" in
pre-C++20 specification) in [func.memfn] are actually requiring them.
This PR adds the missed stuffs. Fixes#86043.
Drive-by changes:
- removing no longer used `__invoke_return`,
- updating synopsis comments in several files, and
- merging several test files for `mem_fn` into one.
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
[template.bitset.general] indicates that `bitset` shouldn't have member
typedef-names `iterator` and `const_iterator`. Currently libc++'s
typedef-names are causing ambiguity in name lookup, which isn't
conforming.
As these iterator types are themselves useful, I think we should just
use __uglified member typedef-names for them.
Fixes#111125
These were split in 0e8208eca1c316b7302de7803ab0d85a1dd77076, with the
only functional difference between them at the time being `--prepend_env
PATH=%{lib-dir}` in the static config and `--prepend_env
PATH=%{install-prefix}/bin` in the shared library config.
However this difference is unnecessary - the static library config
doesn't need any `--prepend_env` argument at all. Before
0e8208eca1c316b7302de7803ab0d85a1dd77076, both configurations used the
same config file, where the `--prepend_env` argument was unnecessary but
benign in the static case.
Reduce the unnecessary config duplication in this case, and return these
configs to using one single config file for both setups.
Currently this test is completely xfailed as part of the patch
https://github.com/llvm/llvm-project/pull/106077. But this test works on
A and R profile, not in v7M profile. Because the test contain cases in
which m-profile will fail for atomic types greater than 4 bytes in size.
