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 patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
This is necessary because e.g. ranges::elements_view uses std::get but
it needs to have in scope the declaration of all the versions of
std::get that exist in the library. This need is what had originally led
to elements_view.h gaining an include of __fwd/complex.h, but in reality
it is a more general issue that requires a canonical declration point
for all the std::get variations.
Add a few missing includes, remove two unnecessary ones and use
__cstddef/size_t.h instead of <cstddef> in a few places. This is a
collection of miscellaneous findings that collectively unblock other
modularization patches.
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.
In essence, this header has always been related to configuration of
the library but we didn't want to put it inside <__config> due to
complexity reasons. Now that we have sub-headers in <__config>, we
can move <__availability> to it and stop including it everywhere since
we already obtain the required macros via <__config>.
std::variant uses multiple macros to generate special member functions.
These macros were very subtle to read because of e.g. a macro argument
appearing in the middle of a macro-ized class definition. In conjunction
with clang-format, this could lead to extremely subtle macro expansions
that were not easy to parse for humans.
By adding semi-colons in macro expansions in judicious places,
clang-format does a better job and makes these macros a lot easier to
read.
As a drive-by fix, I noticed that several of these functions were
missing HIDE_FROM_ABI annotations, so I added them.
#88777 adds a warning for when the `exclude_from_explicit_instantiation`
attribute is applied to local classes and members thereof. This patch
addresses the few instances of `exclude_from_explicit_instantiation`
being applied to local class members in libc++.
The exposition-only type trait `pair-like` includes `ranges::subrange`,
but in every single case excludes `ranges::subrange` from the list. This
patch introduces two new traits `__tuple_like_no_subrange` and
`__pair_like_no_subrange`, which exclude `ranges::subrange` from the
possible matches. `__pair_like` is no longer required, and thus removed.
`__tuple_like` is implemented as `__tuple_like_no_subrange` or a
`ranges::subrange` specialization.
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.
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
While the code is technically correct because the index is never
actually moved from (and anyway that wouldn't matter since it's an
integer), it's still better style not to access an object after it has
been moved-from. Since this is so easy to do, just save the index in a
temporary variable.
rdar://120501577
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 patch re-introduces special support for narrowing conversions to
bool
in std::variant, which was removed in 170810fca6ee in order to make
libc++
Standards-conforming.
The special support is gated by the
`_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT`
macro and will be supported for LLVM 18 only as a courtesy to help large
code bases migrate over to the Standard behavior.
---------
Co-authored-by: Bogdan Graur <bgraur@google.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
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
Committing on behalf of davidben. Reviewed as D146190
Patch originally by Jan Dörrie in https://reviews.llvm.org/D120064. I've just updated it to include tests, and update documentation that MSVC ABI is not stable.
In the current implementation both `std::optional` and `std::variant` don't perform the EBO on MSVC's ABI. This is because both classes inherit from multiple empty base classes, which breaks the EBO for MSVC. This patch fixes this issue by applying the `empty_bases` declspec attribute, which is already used to fix a similar issue for `std::tuple`.
See https://reviews.llvm.org/D120064 for discussion on MSVC ABI stability. From the discussion, libc++ doesn't have users that expect a stable ABI on MSVC. The fix is thus applied unconditionally to benefit more users. Documentation has been updated to reflect this.
Fixes https://github.com/llvm/llvm-project/issues/61095.
We already have a clang-tidy check for making sure that `_LIBCPP_HIDE_FROM_ABI` is on free functions. This patch extends this to class members. The places where we don't check for `_LIBCPP_HIDE_FROM_ABI` are classes for which we have an instantiation in the library.
Reviewed By: ldionne, Mordante, #libc
Spies: jplehr, mikhail.ramalho, sstefan1, libcxx-commits, krytarowski, miyuki, smeenai
Differential Revision: https://reviews.llvm.org/D142332
This results in proper error messages instead of just an abort.
Reviewed By: ldionne, Mordante, #libc
Spies: #libc_vendors, smeenai, libcxx-commits
Differential Revision: https://reviews.llvm.org/D141222
This patch also updates the moved code to the new style (i.e. formatted, replaced marcos and typedefs)
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits
Differential Revision: https://reviews.llvm.org/D145095
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
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
While it's not necessary to qualify calls to `declval` it makes error messages very crypric if the declaration isn't reachable anymore
For example:
```
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<long, long>'
typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>, std::chrono::duration<long, std::ratio<3600, 1>>>' requested here
: public common_type<_Tp, _Tp> {};
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>' requested here
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);}
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days;
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:280:81: error: no type named 'type' in 'std::common_type<std::chrono::duration<long, std::ratio<3600, 1>>>'
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator-() const {return typename common_type<duration>::type(-__rep_);}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:308:54: note: in instantiation of template class 'std::chrono::duration<long, std::ratio<3600, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<24>, hours::period>> days;
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:53:66: error: no type named 'type' in 'std::common_type<int, int>'
typedef chrono::duration<typename common_type<_Rep1, _Rep2>::type,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:107:14: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>, std::chrono::duration<int, std::ratio<86400, 1>>>' requested here
: public common_type<_Tp, _Tp> {};
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:279:58: note: in instantiation of template class 'std::common_type<std::chrono::duration<int, std::ratio<86400, 1>>>' requested here
_LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR typename common_type<duration>::type operator+() const {return typename common_type<duration>::type(*this);}
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__chrono/duration.h:309:55: note: in instantiation of template class 'std::chrono::duration<int, std::ratio<86400, 1>>' requested here
typedef duration< int, ratio_multiply<ratio<7>, days::period>> weeks;
^
19 similar errors omitted
```
changes with qualification added to:
```
While building module 'std' imported from /home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:
In file included from <module-includes>:17:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/math.h:309:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/limits:107:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/type_traits:432:
In file included from /home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_reference.h:13:
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__type_traits/common_type.h:28:43: error: declaration of 'declval' must be imported from module 'std.utility.__utility.declval' before it is required
using __cond_type = decltype(false ? std::declval<_Tp>() : std::declval<_Up>());
^
/home/nikolask/llvm-projects/libcxx/build/include/c++/v1/__utility/declval.h:30:34: note: declaration here is not visible
decltype(std::__declval<_Tp>(0)) declval() _NOEXCEPT;
^
/home/nikolask/llvm-projects/libcxx/libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp:13:10: fatal error: could not build module 'std'
#include <functional>
~~~~~~~~^
2 errors generated.
```
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D130854
`std::variant::operator<=>` is missing a requires clause ensuring that
`operator<=>` only exists when all of the types in the variant are
`three_way_comparable`.
Add the missing requires clause and adjust the existing test which was
incorrect.
Fixes https://github.com/llvm/llvm-project/issues/58192.
Differential Revision: https://reviews.llvm.org/D136050
While testing a test failure of C++17 with Clang ToT it was noticed the
paper
P0602R4 variant and optional should propagate copy/move triviality
was not applied as a DR in libc++.
This was discovered while investigating the issue "caused by" D131479.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133326
This defines a new policy for removal of transitive includes.
The goal of the policy it to make it relatively easy to remove
headers when needed, but avoid breaking developers using and
vendors shipping libc++.
The method used is to guard transitive includes based on the
C++ language version. For the upcoming C++23 we can remove
headers when we want, but for other language versions we try
to keep it to a minimum.
In this code the transitive include of `<chrono>` is removed
since D128577 introduces a header cycle between `<format>`
and `<chrono>`. This cycle is indirectly required by the
Standard. Our cycle dependency tool basically is a grep based
tool, so it needs some hints to ignore cycles. With the input
of our transitive include tests we can create a better tool.
However that's out of the scope of this patch.
Note the flag `_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` remains
unchanged. So users can still opt-out of transitives includes
entirely.
Reviewed By: #libc, ldionne, philnik
Differential Revision: https://reviews.llvm.org/D132284
