This patch reimplements the locale base support for Windows flavors in a
way that is more modules-friendly and without defining non-internal
names.
Since this changes the name of some types and entry points in the built
library, this is effectively an ABI break on Windows (which is
acceptable after checking with the Windows/libc++ maintainers).
It's really not useful at all to run benchmarks without --show-all since
you don't get the benchmark output. And since --show-all is the suggested
default way to run benchmarks, it's not necessary anymore to mention it
right below.
We have a buch of coding guidelines which are either documented as
design docs, which aren't really applicable or not at all. This moves
coding guidelines we have currently in the design docs into a separate
file and adds a bunch of guidelines which we have but aren't documented
anywhere.
This PR optimizes the input iterator overload of `assign(_InputIterator,
_InputIterator)` in `std::vector<_Tp, _Allocator>` by directly assigning
to already initialized memory, rather than first destroying existing
elements and then constructing new ones. By eliminating unnecessary
destruction and construction, the proposed algorithm enhances the
performance by up to 2x for trivial element types (e.g.,
`std::vector<int>`), up to 2.6x for non-trivial element types like
`std::vector<std::string>`, and up to 3.4x for more complex non-trivial
types (e.g., `std::vector<std::vector<int>>`).
### Google Benchmarks
Benchmark tests (`libcxx/test/benchmarks/vector_operations.bench.cpp`)
were conducted for the `assign()` implementations before and after this
patch. The tests focused on trivial element types like
`std::vector<int>`, and non-trivial element types such as
`std::vector<std::string>` and `std::vector<std::vector<int>>`.
#### Before
```
-------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
-------------------------------------------------------------------------------------------------
BM_AssignInputIterIter/vector_int/1024/1024 1157 ns 1169 ns 608188
BM_AssignInputIterIter<32>/vector_string/1024/1024 14559 ns 14710 ns 47277
BM_AssignInputIterIter<32>/vector_vector_int/1024/1024 26846 ns 27129 ns 25925
```
#### After
```
-------------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
-------------------------------------------------------------------------------------------------
BM_AssignInputIterIter/vector_int/1024/1024 561 ns 566 ns 1242251
BM_AssignInputIterIter<32>/vector_string/1024/1024 5604 ns 5664 ns 128365
BM_AssignInputIterIter<32>/vector_vector_int/1024/1024 7927 ns 8012 ns 88579
```
The pointer safety functions were never implemented by anyone in a
non-trivial way, which lead us to removing them entirely from the
headers when they were removed in C++23. This also means that just about
nobody ever called these functions, especially not in production code.
Because of that, we expect there to be no references in the wild to the
functions in the dylib. Because of that, this patch removes the symbols
from the dylib.
This patch introduces a new kind of bounded iterator that knows the size
of its valid range at compile-time, as in std::array. This allows computing
the end of the range from the start of the range and the size, which requires
storing only the start of the range in the iterator instead of both the start
and the size (or start and end). The iterator wrapper is otherwise identical
in design to the existing __bounded_iter.
Since this requires changing the type of the iterators returned by
std::array, this new bounded iterator is controlled by an ABI flag.
As a drive-by, centralize the tests for std::array::operator[] and add
missing tests for OOB operator[] on non-empty arrays.
Fixes#70864
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.
Minor version of releases starts at `N.1.0` for all releases since 4532617ae42005.
The current status pages are not terribly wrong (the version during
development can be considered `N.0`), but still it's kinda weird to use
versions that never get released as the lower bound.
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>
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
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
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
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.
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
This commit changes the libc++ frame recognizer to hide implementation
details of libc++ more aggressively. The applied heuristic is rather
straightforward: We consider every function name starting with `__` as
an implementation detail.
This works pretty neatly for `std::invoke`, `std::function`,
`std::sort`, `std::map::emplace` and many others. Also, this should
align quite nicely with libc++'s general coding convention of using the
`__` for their implementation details, thereby keeping the future
maintenance effort low.
However, this heuristic by itself does not work in 100% of the cases:
E.g., `std::ranges::sort` is not a function, but an object with an
overloaded `operator()`, which means that there is no actual call
`std::ranges::sort` in the call stack. Instead, there is a
`std::ranges::__sort::operator()` call. To make sure that we don't hide
this stack frame, we never hide the frame which represents the entry
point from user code into libc++ code
[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
Only the [cmp.alg] part (for `comparison_meow_fallback` CPOs) in the
paper required changes. Other parts merely fixed preconditions of some
standard library functions.
I strongly feel that P2167R3 should be a DR despite that it is not a DR
officially: CPOs -> C++20; remain parts -> C++98/11 (except that
_`boolean-testable`_ should be transformed into the original
_BooleanTestable_ requirements in the old resolution of LWG2114).
Note that P2167R3 damaged the resolution of LWG3465: the type of `F < E`
was left underconstrained. I've tried to submit an LWG issue for this,
which is now LWG4157.
Drive-by change:
- enable some test coverages in `compare_strong_order_fallback.pass.cpp`
when `TEST_LONG_DOUBLE_IS_DOUBLE`, following up #106742Closes#105241.
This reverts commit 78f9a8b82d772ff04a12ef95f2c9d31ee8f3e409.
This caused the LLDB test `TestDataFormatterGenericOptional.py` to fail, and we need
a bit more time to look into it.
Instead of changing the cast sequence to implicit conversion in
_`voidify`_, I think it is better to totally remove `__voidify` and use
`static_cast` to `void*`, which has equivalent effects.
Test coverage for const iterators are removed.
Now most affected algorithms are underconstrained, for which I submitted
[LWG3888](https://cplusplus.github.io/LWG/issue3888). I'm not sure
whether we should speculatively implement it at this moment, and thus
haven't added any `*.verify.cpp`.
In some control block types and `optional`, the stored objects are
changed to have cv-unqualified type.
Fixes#105119.
The paper was implemented by commit b0386a515b60c
(https://reviews.llvm.org/D46845) in LLVM 7.0. But it would be nice to
have test coverage for desired properties of `insert_return_type`.
Closes#99944
This ABI break only affects fancy pointer which have a different value
representation when pointing to a base of T instead of T itself. This
seems like a rather small set of fancy pointers, which themselves
already represent a very small niche. This patch swaps a pointer to T
with a pointer to base of T in a few library-internal types.
Works towards P0619R4 / #99985.
The use of `std::get_temporary_buffer` and `std::return_temporary_buffer`
are replaced with `unique_ptr`-based RAII buffer holder.
Escape hatches:
- `_LIBCPP_ENABLE_CXX20_REMOVED_TEMPORARY_BUFFER` restores
`std::get_temporary_buffer` and `std::return_temporary_buffer`.
Drive-by changes:
- In `<syncstream>`, states that `get_temporary_buffer` is now removed,
because `<syncstream>` is added in C++20.
This significantly simplifies the code, improves compile times and
improves the object layout of types using `__compressed_pair` in the
unstable ABI. The only downside is that this is extremely ABI sensitive
and pedantically breaks the ABI for empty final types, since the address
of the subobject may change. The ABI of the whole object should not be
affected.
Fixes#91266Fixes#93069
