This patch disables unexpected_disabled_cpp17.verify.cpp under clang
modules builds because it changes diagnostics criteria post #143423,
causing the test to fail.
This patch follows a similar style to 853059a15011fd8b57dd0.
This was found when working on trying to land #144033.
`template <class = int>` is also added to our implementations to avoid
an ambiguity between the libc's version and our version when both are
visible.
This avoids including `<stdlib.h>` in `<math.h>`.
Previously, the segmented iterator optimization was limited to `std::{for_each, for_each_n}`. This patch
extends the optimization to `std::ranges::for_each` and `std::ranges::for_each_n`, ensuring consistent
optimizations across these algorithms. This patch first generalizes the `std` algorithms by introducing
a `Projection` parameter, which is set to `__identity` for the `std` algorithms. Then we let the `ranges`
algorithms to directly call their `std` counterparts with a general `__proj` argument. Benchmarks
demonstrate performance improvements of up to 21.4x for ``std::deque::iterator`` and 22.3x for
``join_view`` of ``vector<vector<char>>``.
Addresses a subtask of #102817.
If optimization is enabled, the inline `f()` function actually gets
inlined, meaning that the functions `tu1()` and `tu2()` trivially return
1 and 2, instead of actually referencing the potentially linker
deduplicated function `f()`, which is what the test tries to test.
Therefore, this test previously actually failed to test what it was
supposed to test, if optimization was enabled.
Mark the inline functions with `TEST_NOINLINE` to make sure that they
don't get inlined even with optimizations enabled.
Also update the TODO comments to explain why we have an XFAIL for msvc
mode here.
This avoids these tests unexpectedly passing if building in msvc mode,
with optimizations enabled
(`-DLIBCXX_TEST_PARAMS="optimization=speed"`).
This newline was originally added in https://reviews.llvm.org/D142184
but I think updating `__libcpp_verbose_abort` to add newline instead is
more consistent, and works for other callers of `_LIBCPP_VERBOSE_ABORT`.
The `_LIBCPP_ASSERTION_HANDLER` calls through to either
`_LIBCPP_VERBOSE_ABORT` macro or the `__builtin_verbose_trap`. From what
I can tell neither of these function expect a trailing newline (at least
none of the usage of `_LIBCPP_VERBOSE_ABORT` or `__builtin_verbose_trap`
that I can find include a trailing newline except `_LIBCPP_ASSERTION_HANDLER`).
I noticed this discrepancy when working on
https://github.com/emscripten-core/emscripten/pull/24543
Updates the implementation `std::reference_wrapper` -
[P2944R3](https://wg21.link/P2944R3) as discussed in
https://github.com/llvm/llvm-project/pull/117664#discussion_r1857826166
This PR also refactors the tests in preparation to implements the
constrained comparisons for `optional`, `variant` etc.
- Moves the test helpers (concepts and types) for testing constrained
comparisons to `test_comparisons.h`.
- Updates the `std::reference_wrapper` implementation to use the concept
`__core_convertible_to<bool>` as per comments in #135759.
Closes#138233
# References:
- [refwrap.comparisons](https://wg21.link/refwrap.comparisons)
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
Parameterize (and rename) existing libc++/libc++abi test configuration
files for the Android NDK to work for both the NDK and platform.
Android LLVM downstream seeks to test libc++ for both the NDK and
platform build (currently only testing the NDK), which will use almost
identical test configuration files. The only difference is the name of
the libc++ shared object used. Because of this we parameterize the
current test files (for both libc++ and libc++abi) with the existing
LIBCXX_SHARED_OUTPUT_NAME cmake variable, and rename the file
accordingly.
Unconditional evaluation of `char_traits<_CharT>::length(__str)` is problematic, because it causes
UB when `__str` points to a non-null-terminated array. We should only call `length` (currently, in
`basic_string_view`'s constructor) when `__n == npos` per [bitset.cons]/8.
Drive-by change: Reduction of conditional compilation, given that
- both `basic_string_view<_CharT>::size_type` and `basic_string<_CharT>::size_type` must be
`size_t`, and thus
- both `basic_string_view<_CharT>::npos` and `basic_string<_CharT>::npos` must be `size_t(-1)`.
For the type sameness in the standard wording, see:
- [string.view.template.general]
- [basic.string.general]
- [allocator.traits.types]/6
- [default.allocator.general]/1
Fixes#143684
This patch does a few things:
- `__libcpp_is_signed_integer` and `__libcpp_is_unsigned_integer` are
refactored to be variable templates instead of class templates.
- the two traits are merged into a single header
`<__type_traits/integer_traits.h>`.
- `__libcpp_signed_integer`, `__libcpp_unsigned_integer` and
`__libcpp_integer` are moved into the same header.
- The above mentioned concepts are renamed to `__signed_integer`,
`__unsigned_integer` and `__signed_or_unsigned_integer` respectively.
This was part of https://wg21.link/p0355r7, but apparently never
implemented.
---------
Co-authored-by: MarcoFalke <*~=`'#}+{/-|&$^_@721217.xyz>
Co-authored-by: Hristo Hristov <zingam@outlook.com>
This patch includes __fwd/span.h in <mdspan> so that we get the
declaration of dynamic_extent inside <mdspan>. We also clean up quite a
few tests that were manually included <span> for dynamic_extent.
This is based on feedback from #142693.
Reviewers: philnik777, ldionne
Reviewed By: philnik777
Pull Request: https://github.com/llvm/llvm-project/pull/142925
This is brought up in the LWG reflector. We currently call `reserve` if
the underlying container has one. But the spec does not specify what
`reserve` should do for Sequence Container. So in theory if the
underlying container is user defined type and it can have a function
called `reserve` which does something completely different.
The fix is to just call `reserve` for STL containers if it has one
See discussion in https://cplusplus.github.io/LWG/issue4239
std::flat_map<std::string, int, std::less<>> m;
m.try_emplace("abc", 5); // hard error
The reason is that we specify in 23.6.8.7 [flat.map.modifiers]/p21
the effect to be as if `ranges::upper_bound` is called.
`ranges::upper_bound` requires indirect_strict_weak_order, which
requires the comparator to be invocable for all combinations. In this
case, it requires
const char (&)[4] < const char (&)[4]
to be well-formed, which is no longer the case in C++26 after
https://wg21.link/P2865R6.
This patch uses `std::upper_bound` instead.
`_ITER_TRAITS` and `_ITER_CONCEPT` are really implenentation details of
`<__iterator/concetps.h>`, so it makes more sense to put them there than
into `<__iterator/iterator_traits.h>`.
The new FTM tests contain text that they validate against to check the
output of the FTM generation script. However, that text lexically
contains the characters `// UNSUPPORTED: <...>`, which leads Lit to make
the whole test unsupported under these conditions. To prevent that from
happening, an `# END.` block can be used to prevent Lit from looking
further into the file for directives.
This patch adds missing <span> includes for std::mdspan tests that use
std::span. There are other cases where we need dynamic_extent that are
handled in #142925.
This was found by running the test suite in the bootstrapping build
with Clang modules enabled.
Currently, when the string shrink into the SSO buffer, the `__rep_.__s`
member isn't activated before the `traits_type::copy` call
yet, so internal `__builtin_memmove` call writing to the buffer causes
constant evaluation failure. The existing test coverage seems a bit
defective and doesn't cover this case - `shrink_to_fit` is called on the
copy of string after erasure, not the original string object.
This PR reorders the `__set_short_size` call, which starts the lifetime
of the SSO buffer, before the copy operation. Test coverage is achieved
by calling `shrink_to_fit` on the original erased string.
The current implementation of `forward_list::resize` does not meet the
strong exception safety guarantee required by [forward.list.modifiers]:
If an exception is thrown by any of these member functions there is no
effect on the container.
This patch refactors `resize()` to provide strong exception safety and
introduces additional tests to validate the strong exception guarantees
for other `forward_list` modifiers.
Fixes#118366.
`common_reference` isn't an exception for [meta.rqmts]/4, so it's better
to disallow users to specialize it.
`indirectly_readable.compile.pass.cpp` was a bit problematic. It
attempted to opt-out common reference type in some wrong ways. Also, the
standard effectively forbids opting-out common reference type for `T&`
and `T&&`. This patch removes and adjusts some problematic cases.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
#109028 caused `sizeof` to be sometimes applied to function reference
types, which makes a program ill-formed. This PR handles reference types
by specializations to prevent such bogus `sizeof` expression to be
instantiated.
Fixes#142118.
Currently, libc++'s `<tuple>` is using the deprecated
`__reference_binds_to_temporary` intrinsic. This PR starts to use
`__reference_constructs_from_temporary` if possible.
It seems that `__reference_constructs_from_temporary` should be used via
an internal type traits provided in
`<__type_traits/reference_constructs_from_temporary.h>`. But given the
old intrinsic was directly used, this PR doesn't switch to the current
convention yet.
P2255R2 is related. Although the paper indicated that constructors of
`tuple` should be deleted in such a case.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
The affected tests are relying on the fact that `MinSequenceContainer`
does not have `insert_range`. This prevents landing of #140287.
This PR creates a new helper class to allow the change in MinSequenceContainer.
Fixes#135351
This PR update CATD guides to associative containers (`std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`).
- Updated template alias for deduction guides for the relevant
associative containers.
- Added a new test to verify the deduction guides with `std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`.
This PR simplifies `__bitset::__init` into a more compact and readable
form, which avoids redundant computations of a `size_t` value and
eliminates the overhead of a local array.
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
The underlying bug in vcruntime [1] has been fixed in the latest version
of MSVC (released two weeks ago); this will cause the test which is
currently marked XFAIL to start erroring, when it starts passing
unexpectedly.
This version of MSVC may soon start appearing in the Github Actions
runner images used for our CI.
We could try to detect the state of this bug, but in practice, such
detection code would essentially be a copy of this whole test.
Therefore, just mark this test UNSUPPORTED for the MSVC mode builds. If
we at some point require new enough MSVC libraries, we could remove the
marking entirely.
[1]
https://developercommunity.visualstudio.com/t/vcruntime-nothrow-array-operator-new-fal/10373274
This patch optimizes `bitset::to_string` by replacing the existing bit-by-bit processing with a more efficient
bit traversal strategy. Instead of checking each bit sequentially, we leverage `std::__countr_zero` to efficiently
locate the next set bit, skipping over consecutive zero bits. This greatly accelerates the conversion process,
especially for sparse `bitset`s where zero bits dominate. To ensure similar improvements for dense `bitset`s, we
exploit symmetry by inverting the bit pattern, allowing us to apply the same optimized traversal technique. Even
for uniformly distributed `bitset`s, the proposed approach offers measurable performance gains over the existing
implementation.
Benchmarks demonstrate substantial improvements, achieving up to 13.5x speedup for sparse `bitset`s with
`Pr(true bit) = 0.1`, 16.1x for dense `bitset`s with `Pr(true bit) = 0.9`, and 8.3x for uniformly distributed
`bitset`s with `Pr(true bit) = 0.5)`.
This patch enhances the performance of `std::for_each_n` when used with
segmented iterators, leading to significant performance improvements,
summarized in the tables below. This addresses a subtask of
https://github.com/llvm/llvm-project/issues/102817.
This generator has almost identical output to the existing script.
Notable differences are
- conditionally include headers that are not implemented yet
- removes the synopsis
- uses 2 spaces indent in `# if`
There are a few more test macros added that triggered bugs in existing
FTM.
