The Trivial Relocation feature has been removed from the C++26 working draft. Based on discussions in Kona, it is unlikely that the "replaceable" type concept will come back in the C++29 time frame. Since we don't have a use for the type trait in the library at the moment, remove the code associated to it. If we end up needing something like it in the future, we can always add it back.
**tl;dr** We can significantly improve the runtime performance of `std::vector` by changing its representation from three pointers to one pointer and two integers. This document explains the details of this change, along with the justifications for making it. See the [RFC] for more information. `vector` depends on `__split_buffer` for inserting elements. Changing `__split_buffer` to match `vector`'s representation simplifies the model, as it eliminates the need to convert between two different representations of a contiguous buffer in the same configuration of libc++. [RFC]: https://discourse.llvm.org/t/adding-a-size-based-vector-to-libc-s-unstable-abi/86306 --------- Co-authored-by: Jorge Gorbe Moya <jgorbe@google.com>
That type trait represents whether move-assigning an object is equivalent to destroying it and then move-constructing a new one from the same argument. This will be useful in a few places where we may want to destroy + construct instead of doing an assignment, in particular when implementing some container operations in terms of relocation. This is effectively adding a library emulation of P2786R12's is_replaceable trait, similarly to what we do for trivial relocation. Eventually, we can replace this library emulation by the real compiler-backed trait. This is building towards #129328.
This set usage of operator& instead of std::addressof seems not be easy to "abuse". Some seem easy to misuse, like basic_ostream::operator<<, trying to do that results in compilation errors since the `widen` function is not specialized for the hijacking character type. Hence there are no tests.
This significantly reduces the amount of debug information generated for codebases using libc++, without hurting the debugging experience.
This PR addresses the improper use of `static_cast` to `size_t` where `size_type` is intended. Although the `size_type` member type of STL containers is usually a synonym of `std::size_t`, there is no guarantee that they are always equivalent. The C++ standard does not mandate this equivalence. In libc++'s implementations of `std::deque`, `std::vector`, and `__split_buffer`, the `size_type` member type is defined as `std::allocator_traits<allocator_type>::size_type`, which is either `allocator_type::size_type` if available or `std::make_unsigned<difference_type>::type`. While it is true for `std::allocator` that the `size_type` member type is `std::size_t`, for user-defined allocator types, they may mismatch. This justifies the need to replace `static_cast<size_t>` with `static_cast<size_type>` in this PR.
This PR fixes the issue where `__split_buffer::shrink_to_fit` may unexpectedly increase the capacity, similar to the issue for `std::vector` in #97895. The fix follows the same approach used in #97895 for `std::vector`.
Related to PR #114423, this PR proposes to unify the naming of the internal pointer members in `std::vector` and `std::__split_buffer` for consistency and clarity. Both `std::vector` and `std::__split_buffer` originally used a `__compressed_pair<pointer, allocator_type>` member named `__end_cap_` to store an internal capacity pointer and an allocator. However, inconsistent naming changes have been made in both classes: - `std::vector` now uses `__cap_` and `__alloc_` for its internal pointer and allocator members. - In contrast, `std::__split_buffer` retains the name `__end_cap_` for the capacity pointer, along with `__alloc_`. This inconsistency between the names `__cap_` and `__end_cap_` has caused confusions (especially to myself when I was working on both classes). I suggest unifying these names by renaming `__end_cap_` to `__cap_` in `std::__split_buffer`.