Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.
This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).
Differential Revision: https://reviews.llvm.org/D153816
Since LIBCXX_ENABLE_FILESYSTEM now truly represents whether the
platform supports a filesystem (as opposed to whether the <filesystem>
library is provided), we can provide a few additional classes from
the <filesystem> library even when the platform does not have support
for a filesystem. For example, this allows performing path manipulations
using std::filesystem::path even on platforms where there is no actual
filesystem.
rdar://107061236
Differential Revision: https://reviews.llvm.org/D152382
These macros are always defined identically, so we can simplify the code a bit by merging them.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, krytarowski, smeenai
Differential Revision: https://reviews.llvm.org/D152652
This makes it clearer that the availability macro only pertains to
<filesystem>, and not to whether the platform has support for a file
system.
Differential Revision: https://reviews.llvm.org/D152172
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
Those were spotted when a project unintentionally started exporting
these symbols from its ABI just by using the libc++ headers.
Differential Revision: https://reviews.llvm.org/D126496
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
This commit reverts 5aaefa51 (and also partly 7f285f48e7 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
This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.
Differential Revision: https://reviews.llvm.org/D119769
The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.
Differential Revision: https://reviews.llvm.org/D118736
The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.
The only non-mechanical diff here is in `<__config>`.
Differential Revision: https://reviews.llvm.org/D118507
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
