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 introduces a new trait to represent whether a type is
trivially
relocatable, and uses that trait to optimize the growth of a std::vector
of trivially relocatable objects.
```
--------------------------------------------------
Benchmark old new
--------------------------------------------------
bm_grow<int> 1354 ns 1301 ns
bm_grow<std::string> 5584 ns 3370 ns
bm_grow<std::unique_ptr<int>> 3506 ns 1994 ns
bm_grow<std::deque<int>> 27114 ns 27209 ns
```
This also changes to order of moving and destroying the objects when
growing the vector. This should not affect our conformance.
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
In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.
We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.
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.
Reviewed By: #libc, ldionne
Spies: ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157753
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 arguments don't get mangled anymore.
Reviewed By: #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157748
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/D157736
POSIX allows certain macros to exist with generic names (i.e. refresh(), move(), and erase()) to exist in `curses.h` which conflict with functions found in std::filesystem, among others. This patch undefs the macros in question and adds them to LIBCPP_PUSH_MACROS and LIBCPP_POP_MACROS.
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D147356
This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.
Reviewed By: ldionne, var-const, #libc
Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei
Differential Revision: https://reviews.llvm.org/D143962
In C++20 the type trait `type_identity` was introduced. For the same purpose there is `__identity` for pre-C++20 code. The name is confusing, because since C++20 there is also `identity`, which isn't a type trait.
Reviewed By: ldionne, Mordante, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D122017
Zero-sized types are a GCC extension, also supported by Clang.
In theory it's already invalid to `delete` a void pointer or a
pointer-to-incomplete, so we shouldn't need any special code
to catch those cases; but in practice Clang accepts both
constructs with just a warning, and GCC even accepts `sizeof(void)`
with just a warning! So we must keep the static_asserts.
The hard errors are tested in `unique_ptr_dltr_dflt/*.compile.fail.cpp`.
In ranges::begin/end, check `sizeof >= 0` instead of `sizeof != 0`,
so as to permit zero-sized types while still disallowing incomplete
types.
Fixes#54100.
Differential Revision: https://reviews.llvm.org/D120633
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
Basically a rebase of D104980; most of that patch had already happened
via gradual drive-by changes, but this finishes it up.
Don't touch the inclusions from `<__functional_base>`, `<__hash_table>`,
or `<__locale>`; those could be removed if we propagated the
inclusions up to the includers of those files, but there are lots
of those includers.
`<algorithm>`, `<functional>`, and `<memory>` already include `<utility>`
at the top level. `<iterator>` did not, so I've added it there.
Differential Revision: https://reviews.llvm.org/D119020
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.
Differential Revision: https://reviews.llvm.org/D116809
According to the C++ standard, the stored pointer and the stored deleter
should be value-initialized.
Differential Revision: https://reviews.llvm.org/D113612
Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.
Differential Revision: https://reviews.llvm.org/D108996
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.
Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.
Differential Revision: https://reviews.llvm.org/D104682
This makes it clear that headers like <memory> which include auto_ptr
only do that when compiling under an older Standard, or when the removed
feature is explicitly requested.
