This test was deadlocking on my machine.
It seems to me the intention of `in_async.wait(...)` was to wait for the
value to be set to true, which requires a call of `wait(false)` (waits
if value matches argument).
~As a drive by change scoped_lock to unique_lock, since there shouldn't
be any functional difference between the two in this test.~
I've addressed the issues with the `in_async` by switching to a
condition variable instead, since my first attempt at fixing this with
`in_async` wasn't sufficient.
libc++ doesn't run clang-tidy in the bootstrapping build, so it wasn't
run when `__builtin_invoke` was introduced. Once libc++ upgrades to a
newer clang version, clang-tidy will start to fail due to missing
`_LIBCPP_NODEBUG` annotations.
`<charconv>` doesn't properly export `std::errc` with locales disabled,
which causes the CI to fail. This fixed the modulemap to let
`from_chars_result` export `std::errc`, like it's supposed to do.
`std::invoke` is currently quite heavy compared to a function call,
since it involves quite heavy SFINAE. This can be done significantly
more efficient by the compiler, since most calls to `std::invoke` are
simple function calls and 6 out of the seven overloads for `std::invoke`
exist only to support member pointers. Even these boil down to a few
relatively simple checks.
Some real-world testing with this patch revealed some significant
results. For example, instantiating `std::format("Banane")` (and its
callees) went down from ~125ms on my system to ~104ms.
Fixes#108624
This allows `flat_map::insert(Iter, Iter)` to directly forward to
underlying containers' `insert(Iter, Iter)`, instead of inserting one
element at a time, when input models "product iterator". atm,
`flat_map::iterator` and `zip_view::iterator` are "product iterator"s.
This gives about almost 10x speed up in my benchmark with -03 (for both
before and after)
```cpp
Benchmark Time CPU Time Old Time New CPU Old CPU New
-----------------------------------------------------------------------------------------------------------------------------------------------
flat_map::insert_product_iterator_flat_map/32 -0.5028 -0.5320 149 74 149 70
flat_map::insert_product_iterator_flat_map/1024 -0.8617 -0.8618 3113 430 3112 430
flat_map::insert_product_iterator_flat_map/8192 -0.8877 -0.8877 26682 2995 26679 2995
flat_map::insert_product_iterator_flat_map/65536 -0.8769 -0.8769 226235 27844 226221 27841
flat_map::insert_product_iterator_zip/32 -0.5844 -0.5844 162 67 162 67
flat_map::insert_product_iterator_zip/1024 -0.8754 -0.8754 3427 427 3427 427
flat_map::insert_product_iterator_zip/8192 -0.8934 -0.8934 28134 3000 28132 3000
flat_map::insert_product_iterator_zip/65536 -0.8783 -0.8783 229783 27960 229767 27958
OVERALL_GEOMEAN -0.8319 -0.8332 0 0 0 0
```
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This patch adds a separate `extensions` directory, since there are quite
a few extensions in libc++ that aren't necessarily libc++-specific. For
example, the tests currently in `libcxx/test/libcxx/extensions` should
also pass with libstdc++, since they originally added the extension.
This also "documents" what users are allowed to rely on and what parts
are just libc++ tests to make sure our implementation is behaving as we
expect, which may be subject to change.
This patch also formats the tests and refactors `.fail.cpp` tests to
`.verify.cpp` tests.
Most of the diff is replacing `__parent_pointer` with
`__end_node_pointer`. The most interesting diff is that the pointer
aliases are now defined directly inside `__tree` instead of a separate
traits class.
This patch is very similar to #134819 in nature. Before this patch, we
were dereferencing pointers to objects which were never constructed. Now
we always assume that nodes store `pair<const KeyT, ValueT>` for
unordered_maps instead, as they actually do.
If the creation of a thread fails, this causes an idle loop that will
never end because the thread wasn't started in the first place.
This also adds a test for the regression reported in #125433 to make
sure we're not reintroducing it later.
Fixes#125428
Refactor the function to streamline the logic so it matches the
specification in [filebuf.virtuals] more closely. In particular, avoid
modifying the put area pointers when we loop around after a partial
codecvt conversion.
Note that we're technically not up-to-spec in this implementation, since
the Standard says that we shouldn't try more than once after a partial
codecvt conversion. However, this refactoring attempts not to change any
functionality.
This patch addresses several implementation issues in `bitset`'s
conversion functions `to_ullong` and `to_ulong`, and refactors its
converting constructor `__bitset(unsigned long long __v)` to a more
generic and elegant implementation.
Most notably, this removes the notion of a distinct `value_type` and
`__container_value_type` from `__tree`, since these are now always the
same type. There are a few places we need to keep `__value_type` around,
since they are ABI visibile. In these cases `_Tp` is used directly. The
second simplification here is that we use `const value_type&` instead of
`const key_type&` in a few places and make use of the fact that the
comparator is capable of comparing any combination of `key_type` and
`value_type`.
This is a follow-up to #134819.
This does a few small things:
- inline `__libcpp_compute_min`, since we can don't have to put the
arithmetic behind a constraint. Simple arithmetic also tends to be
faster to compile than instantiating a type.
- Remove an unused include (and add missing includes elsewhere)
- Remove `__min` and `__max` from the `bool` specialization
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Since we've removed allocator support, we can remove a few support
structures. This only affects the policy implementation, so this
shouldn't even be ABI sensitive.
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 853059a150.
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.
`__has_iterator_typedefs` is only used in the up-to-C++17 implementation
of `type_traits`. To make that clearer the struct is moved into that
code block.
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
The implementation of std::basic_streambuf used private member variables
to manipulate the get and the put areas. Using public API functions is
equivalent but leads to code that is easier to understand, since the
public API functions are known more widely than our internal member
variables. Using the public API functions removes the need to map the
internal member variables back to get/put area manipulation functions in
one's head.
Finally, it also makes it easier to find subtle issues by instrumenting
accessor functions, which is impossible if the class uses the member
variables directly.
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