| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
(#139632)
**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.
|
|
`__split_buffer` (#117720)
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`.
|
|
std::__split_buffer (#115517)
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`.
|
|
|
|
This is possible since we're not using `__compressed_pair` anymore.
|
|
This PR refactors the `__split_buffer` class to eliminate code
duplication in the `push_back` and `push_front` member functions.
**Motivation:**
The lvalue and rvalue reference overloads of `push_back` share identical
logic, which coincides with that of `emplace_back`. Similarly, the
overloads of `push_front` also share identical logic but lack an
`emplace_front` member function, leading to an inconsistency. These
identical internal logics lead to significant code duplication, making
future maintenance more difficult.
**Summary of Refactor:**
This PR reduces code redundancy by:
1. Modifying both overloads of `push_back` to call `emplace_back`.
2. Introducing a new `emplace_front` member function that encapsulates
the logic of `push_front`, allowing both overloads of `push_front` to
call it (The addition of `emplace_front` also avoids the inconsistency
regarding the absence of `emplace_front`).
The refactoring results in reduced code duplication, improved
maintainability, and enhanced readability.
|
|
|
|
Currently, the occurrences of `__add_lvalue_reference_t` in
`__split_buffer` and `__assoc_state` are probably meaningless.
* In `__split_buffer`, the `__alloc_ref` and `__alloc_const_ref` member
typedefs are no longer used.
* In `__assoc_state`, we should simply use `_Rp&`, which must be
well-formed since it's already required that `sizeof(_Rp)` is
well-formed.
This PR removes the meaningless usages. The remaining occurrences in
`shared_ptr`, `unique_ptr`, and several type traits are meaningful.
|
|
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
|
|
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 #91266
Fixes #93069
|
|
As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.
We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.
|
|
This changes the `is_swappable` implementation to use variable templates
first and basing the class templates on that. This avoids instantiating
them when the `_v` versions are used, which are generally less resource
intensive.
|
|
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308)
These headers have become very small by using compiler builtins, often
containing only two declarations. This merges these headers, since
there doesn't seem to be much of a benefit keeping them separate.
Specifically, `is_{,_nothrow,_trivially}{assignable,constructible}` are
kept and the `copy`, `move` and `default` versions of these type traits
are moved in to the respective headers.
|
|
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.
This patch was generated with:
find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i
A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.
[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
|
|
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.
See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
|
|
This brings most of the enable_ifs in libc++ to the same style. It also has the nice side-effect of reducing the size of names of these symbols, since the depedent return type is shorter.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157787
|
|
check //only// the iterator category
We plan to add concepts for checking that iterators actually provide what they claim to. This is to avoid people thinking that these type traits actually check the iterator requirements in more detail.
Reviewed By: ldionne, #libc
Spies: Mordante, libcxx-commits, wenlei
Differential Revision: https://reviews.llvm.org/D150801
|
|
- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.
(Note: this patch is split from https://reviews.llvm.org/D142335)
Differential Revision: https://reviews.llvm.org/D149826
|
|
Reviewed By: ldionne, #libc, #libc_abi
Spies: #libc_vendors, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145320
|
|
inline into the class body
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D142433
|
|
Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits, smeenai
Differential Revision: https://reviews.llvm.org/D143163
|
|
Reviewed By: #libc, ldionne
Spies: jwakely, beanz, smeenai, cfe-commits, tschuett, avogelsgesang, Mordante, sstefan1, libcxx-commits, ldionne, mgorny, arichardson, miyuki
Differential Revision: https://reviews.llvm.org/D131963
|
|
Reviewed By: ldionne, huixie90, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D134479
|
|
Use `using` aliases to avoid instantiating lots of types
Reviewed By: ldionne, #libc
Spies: libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D132785
|
|
Reviewed By: ldionne, #libc
Spies: vitalybuka, paulkirth, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D132790
|
|
Breaks buildbots.
This reverts commit 30adaa730c4768b5eb06719c808b2884fcf53cf3.
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D132790
|
|
This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
|
|
_LIBCPP_HIDE_FROM_ABI in __split_buffer
Reviewed By: ldionne, huixie90, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D132028
|
|
Reviewed By: Mordante, huixie90, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D132032
|
|
Reviewed By: #libc, ldionne
Spies: mgorny, var-const, ormris, philnik, miscco, hiraditya, steven_wu, jkorous, ldionne, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D68365
|
|
Reviewed By: ldionne, #libc
Spies: huixie90, eaeltsin, joanahalili, bgraur, alexfh, hans, avogelsgesang, augusto2112, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D128146
|
|
This reverts commit 23cf42e706fbc2a939ce1470da16599b42258aea.
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D128146
|
|
|
|
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D128646
|
|
Reviewed By: ldionne, #libc
Spies: jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128400
|
|
Reviewed By: ldionne, var-const, #libc
Spies: mgorny, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D122877
|
|
|
|
This commit reverts 5aaefa51 (and also partly 7f285f48e77 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.
Differential Revision: https://reviews.llvm.org/D120683
|
|
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
Differential Revision: https://reviews.llvm.org/D106124
|
|
Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi
Spies: #libc_vendors, libcxx-commits, miyuki
Differential Revision: https://reviews.llvm.org/D119667
|
|
Now we'll notice if a header forgets to include this magic phrase.
Differential Revision: https://reviews.llvm.org/D118800
|
