This patch adds the following pieces to the locale base API:
- __setlocale (for std::setlocale)
- __lconv_t (for std::lconv)
- _LIBCPP_FOO_MASK and _LIBCPP_LC_ALL
This should be sufficient to implement all of the platform-agnostic
localization support in libc++ without relying directly on any public
API names from the C library. This makes it possible to port libc++ to
platforms that don't provide the usual locale APIs.
This changes the __output_buffer to a new structure. This improves the
performace of std::format, std::format_to, std::format_to_n, and
std::formatted_size.
The old and new implementation of `_And` are very close in terms of
performance according to my testing, but the new implementation can also
be used to implement `conjunction`, which make that ~50% faster.
The commit 24e70e3930724ce499ad05d669bfbc4423c542e0 changed internal
macros which were used in 0cd794d4860e376698bb4da24bcdf8cbf331835c.
This caused build failures on platforms without TZDB support
While implementing this feature and its associated LWG issues it turns
out
- LWG3316 Correctly define epoch for utc_clock / utc_timepoint only
added non-normative wording to the standard.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
- P1361 Integration of chrono with text formatting
- LWG3359 <chrono> leap second support should allow for negative leap
seconds
This is a continuation of what's been started in #89178.
As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL`
instead of `INCOMPLETE`.
Some templates in the standard library are illegal to specialize for users
(even if the specialization contains user-defined types). The [[clang::no_specializations]]
attribute allows marking such base templates so that the compiler will
diagnose if users try adding a specialization.
This changes the implementation of `__copy_cvref_t` to only template the
implementation class on the `_From` parameter, avoiding instantiations
for every combination of `_From` and `_To`.
Changes:
- Carve out sized but input-only ranges for C++23.
- Call `std::move` for related functions when the iterator is possibly input-only.
Fixes#115727
By calling `std::move` for related functions when the iterator is
possibly input-only. Also slightly changes the conditions of branch for
contiguous iterators to avoid error.
Fixes#116502
This PR addresses an issue where the `shrink_to_fit` function in
`vector<bool>` is effectively a no-op, meaning it will never shrink the
capacity.
Fixes#122502
Currently we're using quite different internal names for the
`std::invoke` family of type traits. This adds a layer around the
current implementation to make it easier to understand when it is used
and makes it easier to define multiple implementations of it.
In https://reviews.llvm.org/D136765 / https://reviews.llvm.org/D144155,
the asan annotations for `std::vector` were modified to unpoison freed
backing memory on destruction, instead of leaving it poisoned. However,
calling `__clear()` instead of `clear()` skips informing the asan runtime
of this decrease in the accessible container size, which breaks the
invariant that the value of `old_mid` should match the value of `new_mid`
from the previous call to `__sanitizer_annotate_contiguous_container`, which
can trip the sanity checks for the partial poison between [d1, d2) and the
container redzone between [d2, c), if enabled. To fix this, ensure that
`clear()` is called instead, as is already done by `__vdeallocate()`.
Also remove `__clear()`, since it is no longer called.
https://github.com/llvm/llvm-project/pull/95498 implemented a libc++
extension where <stdatomic.h> would forward to <atomic> even before
C++23. Unfortunately, this was found to be a breaking change (with
fairly widespread impact) since that changes whether _Atomic(T) is a C
style atomic or std::atomic<T>. In principle, this can even be an ABI
break.
We generally don't implement extensions in libc++ because they cause so
many problems, and that extension had been accepted because it was
deemed pretty small and only a quality of life improvement. Since it has
widespread impact on valid C++20 (and before) code, this patch removes
the extension before we ship it in any public release.
`_LIBCPP_NODEBUG` has been disabled temporarily, since there were a few
problems when adding a bunch of annotations throughout the code base.
They have been resolved now, so we can enable all the annotations again.
Reverts llvm/llvm-project#122393
Missing information about begin and end pointers of std::vector can lead
to missed optimizations in LLVM.
This patch adds alignment assumptions at the point where the begin and
end pointers are loaded. If the pointers would not have the same
alignment, end might never get hit when incrementing begin.
See https://github.com/llvm/llvm-project/issues/101372 for a discussion
of missed range check optimizations in hardened mode.
Once https://github.com/llvm/llvm-project/pull/108958 lands, the created
`llvm.assume` calls for the alignment should be folded into the `load`
instructions, resulting in no extra instructions after InstCombine.
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
There doesn't seem to be much benefit in always providing declarations
for the sized deallocations from C++14 onwards if the user explicitly
passed `-fno-sized-deallocation` to disable them. This patch simplifies
the declarations to be available exactly when the compiler expects sized
deallocation functions to be available.
As a follow-up to #113852, this PR optimizes the performance of the
`insert(const_iterator pos, InputIt first, InputIt last)` function for
`input_iterator`-pair inputs in `std::vector` for cases where
reallocation occurs during insertion. Additionally, this optimization
enhances exception safety by replacing the traditional `try-catch`
mechanism with a modern exception guard for the `insert` function.
The optimization targets cases where insertion trigger reallocation. In
scenarios without reallocation, the implementation remains unchanged.
Previous implementation
-----------------------
The previous implementation of `insert` is inefficient in reallocation
scenarios because it performs the following steps separately:
- `reserve()`: This leads to the first round of relocating old
elements to new memory;
- `rotate()`: This leads to the second round of reorganizing the
existing elements;
- Move-forward: Moves the elements after the insertion position to
their final positions.
- Insert: performs the actual insertion.
This approach results in a lot of redundant operations, requiring the
elements to undergo three rounds of relocations/reorganizations to be
placed in their final positions.
Proposed implementation
-----------------------
The proposed implementation jointly optimize the above 4 steps in the
previous implementation such that each element is placed in its final
position in just one round of relocation. Specifically, this
optimization reduces the total cost from 2 relocations + 1 std::rotate
call to just 1 relocation, without needing to call `std::rotate`,
thereby significantly improving overall performance.
This PR fixes the ambiguities in name lookup caused by non-standard
member typedefs `size_type` and `difference_type` in `std::bitset`.
Follows up #121620.
Closes#121618.
Currently, when the result type is 1-`tuple`, `tuple_cat` possibly tests
an undesired constructor of the element, due to conversion from the
reference tuple to the result type. If the element type has an
unconstrained constructor template, there can be extraneous hard error
which shouldn't happen.
This patch introduces a helper function template to select the element-wise
constructor template of `tuple`, which can avoid such error.
Fixes#41034.
Implementing `constexpr std::stable_sort`. This is part of P2562R1,
tracked via issue #105360.
Closes#119394
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
This follows the same path we've been doing for all platforms so far,
moving away from the old definition of the locale base API.
Co-authored-by: Daniel Thornburgh <mysterymath@gmail.com>
Currently, places where we call __libcpp_allocate must drop type
information on the ground even when they actually have such information
available. That is unfortunate since some toolchains and system
allocators are able to provide improved security when they know what
type is being allocated.
This is the purpose of http://wg21.link/p2719, where we introduce a new
variant of `operator new` which takes a type in its interface. A
different but related issue is that `std::allocator` does not honor any
in-class `T::operator new` since it is specified to call the global
`::operator new` instead.
This patch closes the gap to make it trivial for implementations that
provide typed memory allocators to actually benefit from that
information in more contexts, and also makes libc++ forward-compatible
with future proposals that would fix the existing defects in
`std::allocator`. It also makes the internal allocation API higher level
by operating on objects instead of operating on bytes of memory.
Since this is a widely-used function and making this a template could
have an impact on debug info sizes, I tried minimizing the number of
templated layers by removing `__do_deallocate_handle_size`, which was
easy to replace with a macro (and IMO this leads to cleaner code).
The isascii() function is not standard, so we should avoid relying on
the platform providing it, especially since it's easy to implement in
libc++ portably.
