[libc++] Simplify type_traits and use more builtins

[ldionne]

libcxx/include/__type_traits/is_arithmetic.h

23 ↗

(On Diff #434841)

On what compilers is this not supported?

libcxx/include/__type_traits/is_compound.h

22

On what compilers is __is_compound not supported?

libcxx/include/__type_traits/is_floating_point.h

22 ↗

(On Diff #434841)

Same question!

libcxx/include/__type_traits/is_function.h

23–27

Ditto.

libcxx/include/__type_traits/is_fundamental.h

22–23

The comments are now stale. Also, can we simply assume that we have __is_fundamental?

libcxx/include/__type_traits/is_unsigned.h

22–23

22–24

I'm pretty sure the latest AppleClang 14 beta is fixed. Once it's out of the beta, we can even drop this conditional altogether since it'll be the only AppleClang version we support (per our policy).

[philnik]

• Address comments

libcxx/include/__type_traits/is_arithmetic.h

23 ↗

(On Diff #434841)

In all cases GCC. Should I guard them with #ifndef _LIBCPP_COMPILER_GCC?

libcxx/include/__type_traits/is_fundamental.h

22–23

Nope, GCC also doesn't support __is_fundamental.

[ldionne]

LGTM, but can you please rebase to poke CI and get it green? I'd like to see this pass on all the compilers + platforms we have.

libcxx/include/__type_traits/is_arithmetic.h

23 ↗

(On Diff #434841)

No, I guess it's OK to keep it as-is.

[philnik]

• Address comments

[alanphipps]

Hello! I'm noticing test failures with our downstream Arm compiler that may be related to the changes you're making, but I'm not sure where to begin looking.

I'm seeing the following error:

./include/c++/v1/__functional/invoke.h:14:10: fatal error: '__type_traits/add_lvalue_reference.h' file not found
#include <__type_traits/add_lvalue_reference.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Did something happen to how add_lvalue_reference.h is installed? Looks like there were changes to the modulemap. Thanks for your help.

[philnik]

In D127226#3574967, @alanphipps wrote:

Hello! I'm noticing test failures with our downstream Arm compiler that may be related to the changes you're making, but I'm not sure where to begin looking.

I'm seeing the following error:

./include/c++/v1/__functional/invoke.h:14:10: fatal error: '__type_traits/add_lvalue_reference.h' file not found
#include <__type_traits/add_lvalue_reference.h>
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Did something happen to how add_lvalue_reference.h is installed? Looks like there were changes to the modulemap. Thanks for your help.

add_lvalue_reference has been added in D126244, but I don't think there is anything different from the other granularization patches. Did anything fail like this before?

[alanphipps]

In D127226#3574990, @philnik wrote:

add_lvalue_reference has been added in D126244, but I don't think there is anything different from the other granularization patches. Did anything fail like this before?

Nope, it was working fine until a few hours ago. The only files I see actually installed in include/c++/v1/__type_traits/ are "integral_constant.h" and "is_callable.h".

[alanphipps]

In D127226#3575067, @alanphipps wrote:

Nope, it was working fine until a few hours ago. The only files I see actually installed in include/c++/v1/__type_traits/ are "integral_constant.h" and "is_callable.h".

I confirmed this was due to problem in our build environment. Sorry for the bother!

[ayzhao]

This is causing build breakages in Chrome as we use std::numeric_limits<__float128>.

After this change, std::is_arithmetic<__float128>::value is now true instead of false [0]. Observe that for GCC's libstdc++, the value is also false.

This causes std::numeric_limits<__float128> to fail to compile [1]. This is because std::numeric_limits inherits from __libcpp_numeric_limits, which refers to std::is_arithmetic in its template parameters. The change from false to true causes libc++ to instantiate some illegal template usages of __float128.

[0]: https://godbolt.org/z/EjnY8Th1d Note: at the time of this comment, the output of x86-64 clang(trunk) returned 1 - everything else returns 0.
[1]: https://godbolt.org/z/94PhTsabf Note: at the time of this comment, the output of x86-64 clang(trunk) is https://pastebin.com/w0kRFqB0
[2]: https://github.com/llvm/llvm-project/blob/911841f717eb8acaccf4f3deb5f85fbf6903f55f/libcxx/include/limits#L144-L145

[philnik]

In D127226#3590332, @ayzhao wrote:

This is causing build breakages in Chrome as we use std::numeric_limits<__float128>.

After this change, std::is_arithmetic<__float128>::value is now true instead of false [0]. Observe that for GCC's libstdc++, the value is also false.

This causes std::numeric_limits<__float128> to fail to compile [1]. This is because std::numeric_limits inherits from __libcpp_numeric_limits, which refers to std::is_arithmetic in its template parameters. The change from false to true causes libc++ to instantiate some illegal template usages of __float128.

[0]: https://godbolt.org/z/EjnY8Th1d Note: at the time of this comment, the output of x86-64 clang(trunk) returned 1 - everything else returns 0.
[1]: https://godbolt.org/z/94PhTsabf Note: at the time of this comment, the output of x86-64 clang(trunk) is https://pastebin.com/w0kRFqB0
[2]: https://github.com/llvm/llvm-project/blob/911841f717eb8acaccf4f3deb5f85fbf6903f55f/libcxx/include/limits#L144-L145

It's not clear to me what you are asking for. Do you think std::is_arithmetic_v<__float128> should return false? Do you want a numeric_limits specialization of __float128?

[ayzhao]

In D127226#3592731, @philnik wrote:

In D127226#3590332, @ayzhao wrote:

This is causing build breakages in Chrome as we use std::numeric_limits<__float128>.

After this change, std::is_arithmetic<__float128>::value is now true instead of false [0]. Observe that for GCC's libstdc++, the value is also false.

This causes std::numeric_limits<__float128> to fail to compile [1]. This is because std::numeric_limits inherits from __libcpp_numeric_limits, which refers to std::is_arithmetic in its template parameters. The change from false to true causes libc++ to instantiate some illegal template usages of __float128.

[0]: https://godbolt.org/z/EjnY8Th1d Note: at the time of this comment, the output of x86-64 clang(trunk) returned 1 - everything else returns 0.
[1]: https://godbolt.org/z/94PhTsabf Note: at the time of this comment, the output of x86-64 clang(trunk) is https://pastebin.com/w0kRFqB0
[2]: https://github.com/llvm/llvm-project/blob/911841f717eb8acaccf4f3deb5f85fbf6903f55f/libcxx/include/limits#L144-L145

It's not clear to me what you are asking for. Do you think std::is_arithmetic_v<__float128> should return false? Do you want a numeric_limits specialization of __float128?

I don't mean to make a specific recommendation here as I'm not as familiar with libc++. My main point is that this patch causes numeric_limits<__float128> (and very likely many other non-standard types) to fail to build, and that this breakage should be fixed in one way or another. The points I made referencing std::is_arithmetic were to explain why this patch causes the aforementioned build breakage. Whether or not std::is_arithmetic_v<__float128> should return false is something that I'd rather have someone more experienced decide, but I will note that the behavior is now different between libc++ and libstdc++.

[manojgupta]

This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.

[manojgupta]

https://godbolt.org/z/16bhGfM9d

The following code now longer works after this patch:

#include <limits>

__float128 test() {
    return std::numeric_limits<__float128>::min();
}

@ldionne can you please suggest the best course here? I'll note that this same breakage has happened a few years back and at that time a fix was made (https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202) which is now undone by this change.

[cjdb]

In D127226#3593385, @ayzhao wrote:

In D127226#3592731, @philnik wrote:

In D127226#3590332, @ayzhao wrote:

This is causing build breakages in Chrome as we use std::numeric_limits<__float128>.

After this change, std::is_arithmetic<__float128>::value is now true instead of false [0]. Observe that for GCC's libstdc++, the value is also false.

This causes std::numeric_limits<__float128> to fail to compile [1]. This is because std::numeric_limits inherits from __libcpp_numeric_limits, which refers to std::is_arithmetic in its template parameters. The change from false to true causes libc++ to instantiate some illegal template usages of __float128.

[0]: https://godbolt.org/z/EjnY8Th1d Note: at the time of this comment, the output of x86-64 clang(trunk) returned 1 - everything else returns 0.
[1]: https://godbolt.org/z/94PhTsabf Note: at the time of this comment, the output of x86-64 clang(trunk) is https://pastebin.com/w0kRFqB0
[2]: https://github.com/llvm/llvm-project/blob/911841f717eb8acaccf4f3deb5f85fbf6903f55f/libcxx/include/limits#L144-L145

It's not clear to me what you are asking for. Do you think std::is_arithmetic_v<__float128> should return false? Do you want a numeric_limits specialization of __float128?

I don't mean to make a specific recommendation here as I'm not as familiar with libc++. My main point is that this patch causes numeric_limits<__float128> (and very likely many other non-standard types) to fail to build, and that this breakage should be fixed in one way or another. The points I made referencing std::is_arithmetic were to explain why this patch causes the aforementioned build breakage. Whether or not std::is_arithmetic_v<__float128> should return false is something that I'd rather have someone more experienced decide, but I will note that the behavior is now different between libc++ and libstdc++.

is_arithmetic_v<__float128> should be true if __float128 is a compiler-supported floating-point number IMO. It should be noted that __is_integral(__int128) and __is_arithmetic(__int128) are both true, so I don't see why __float128 should be any different.

However, this probably means numeric_limits<__float128> will need a specialisation, if it doesn't already have one.

[Mordante]

In D127226#3602787, @manojgupta wrote:

This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.

Unfortunately it seems this revert wasn't followed up by a regression test.

I agree we should fix this and add tests for __float128 and for other non-standard types broken by this commit.
That way we can avoid future regressions.

I think we should also have a look at the gcc/clang manuals for additional non-standard types and evaluate their status.

@ayzhao, @manojgupta, @cjdb are you aware of other types that are broken by this commit?

[cjdb]

In D127226#3603886, @Mordante wrote:

In D127226#3602787, @manojgupta wrote:

This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.

Unfortunately it seems this revert wasn't followed up by a regression test.

I agree we should fix this and add tests for __float128 and for other non-standard types broken by this commit.
That way we can avoid future regressions.

I think we should also have a look at the gcc/clang manuals for additional non-standard types and evaluate their status.

@ayzhao, @manojgupta, @cjdb are you aware of other types that are broken by this commit?

Nothing to my knowledge, but you may want to double check that __int128 and _BitInt(n) haven't regressed too.

[ayzhao]

In D127226#3603886, @Mordante wrote:

In D127226#3602787, @manojgupta wrote:

This seems like same as the problem that was fixed by https://reviews.llvm.org/rGe6a39f00e8d0cd3684df54fb03d288efe2969202 and re-introduced by this patch.

Unfortunately it seems this revert wasn't followed up by a regression test.

I agree we should fix this and add tests for __float128 and for other non-standard types broken by this commit.
That way we can avoid future regressions.

I think we should also have a look at the gcc/clang manuals for additional non-standard types and evaluate their status.

@ayzhao, @manojgupta, @cjdb are you aware of other types that are broken by this commit?

I don't know of any others off of the top of my head, but based on the definition of __is_arithmetic(...), all of the following types are now suspect: https://github.com/llvm/llvm-project/blob/1b24fe34b06cd9f2337313f513a8b19f9a37c5de/clang/include/clang/AST/BuiltinTypes.def#L62-L222

[manojgupta]

@philnik @ldionne Can this patch please be reverted? There are clear test cases that it breaks.

[philnik]

In D127226#3609649, @manojgupta wrote:

@philnik @ldionne Can this patch please be reverted? There are clear test cases that it breaks.

I agree that we should fix the problem, but I don't know how. The right approach seems to be to return true for is_arithmetic_v<__float128> and add a __float128 specialization to numeric_limits. The problem there is that clang doesn't provide the macros to implement it properly. That would mean we have to implement it on a best-effort basis, which doesn't sound great IMO. The other option would be to return false for is_arithmetic_v<__float128>, which is obviously a lie. Neither option sounds great. I think both the current state of is_arithmetic_v<__float128> == true and the old state of is_arithmetic_v<__float128> == false are fundamentally broken. We don't have any tests for either of them, which means that it's a bug waiting to happen.
I will talk to @ldionne about this next week and after that either partially revert this patch and add regression tests or add a specialization to numeric_limits. IMO we shouldn't revert it right now, since it would only change the problem we have and not remove a problem. If you can't wait until Wednesday or Thursday you can always revert the diff downstream.

[Mordante]

@ayzhao, @cjdb Thanks for the additional information.

@philnik Is there a conflict in reverting this commit? The general LLVM policy is to keep HEAD in working order. I assume the breakage blocks people from testing HEAD so other patches after this commit are might not tested downstream until HEAD works again.

I'm in favor for a quick (partial) revert, fix it, and re-land the fixed version.

[manojgupta]

If you can't wait until Wednesday or Thursday you can always revert the diff downstream.

In D127226#3610114, @Mordante wrote:

@ayzhao, @cjdb Thanks for the additional information.

@philnik Is there a conflict in reverting this commit? The general LLVM policy is to keep HEAD in working order. I assume the breakage blocks people from testing HEAD so other patches after this commit are might not tested downstream until HEAD works again.

I'm in favor for a quick (partial) revert, fix it, and re-land the fixed version.

I do not think delaying by a week is a good timeline. I have reverted it for now since this is known to break multiple CIs.

[hans]

Did the reland in https://reviews.llvm.org/rG31ae52859f7a2339f31bb78c5163c23cb872f179 address the issue raised by Alan and Manoj? The commit message only says "Stuff" :-)

[philnik]

In D127226#3611365, @hans wrote:

Did the reland in https://reviews.llvm.org/rG31ae52859f7a2339f31bb78c5163c23cb872f179 address the issue raised by Alan and Manoj? The commit message only says "Stuff" :-)

Yes I removed these parts for now. The "Stuff" in there wasn't planned, sorry.

[cjdb]

In D127226#3611394, @philnik wrote:

In D127226#3611365, @hans wrote:

Did the reland in https://reviews.llvm.org/rG31ae52859f7a2339f31bb78c5163c23cb872f179 address the issue raised by Alan and Manoj? The commit message only says "Stuff" :-)

Yes I removed these parts for now. The "Stuff" in there wasn't planned, sorry.

In future, would you mind adding something to describe that the problematic parts have been removed please? It'll make it easier to vet the changes because we'll know what to look for.

[philnik]

In D127226#3612405, @cjdb wrote:

In D127226#3611394, @philnik wrote:

In D127226#3611365, @hans wrote:

Did the reland in https://reviews.llvm.org/rG31ae52859f7a2339f31bb78c5163c23cb872f179 address the issue raised by Alan and Manoj? The commit message only says "Stuff" :-)

Yes I removed these parts for now. The "Stuff" in there wasn't planned, sorry.

In future, would you mind adding something to describe that the problematic parts have been removed please? It'll make it easier to vet the changes because we'll know what to look for.

Yes I'll do that. I thought I had a better commit message than "Stuff".

libcxx/include/__type_traits/is_abstract.h

 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_abstract
     : public integral_constant<bool, __is_abstract(_Tp)> {};
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
-inline constexpr bool is_abstract_v = is_abstract<_Tp>::value;
+inline constexpr bool is_abstract_v = __is_abstract(_Tp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_ABSTRACT_H

libcxx/include/__type_traits/is_aggregate.h

 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if _LIBCPP_STD_VER > 14
 
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS
 is_aggregate : public integral_constant<bool, __is_aggregate(_Tp)> {};
 
 template <class _Tp>
-inline constexpr bool is_aggregate_v = is_aggregate<_Tp>::value;
+inline constexpr bool is_aggregate_v = __is_aggregate(_Tp);
 
 #endif // _LIBCPP_STD_VER > 14
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_AGGREGATE_H

libcxx/include/__type_traits/is_base_of.h

 _LIBCPP_BEGIN_NAMESPACE_STD
 
 template <class _Bp, class _Dp>
 struct _LIBCPP_TEMPLATE_VIS is_base_of
     : public integral_constant<bool, __is_base_of(_Bp, _Dp)> {};
 
 #if _LIBCPP_STD_VER > 14
 template <class _Bp, class _Dp>
-inline constexpr bool is_base_of_v = is_base_of<_Bp, _Dp>::value;
+inline constexpr bool is_base_of_v = __is_base_of(_Bp, _Dp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_BASE_OF_H

libcxx/include/__type_traits/is_class.h

 #include <__type_traits/remove_cv.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#if __has_feature(is_class) || defined(_LIBCPP_COMPILER_GCC)
-
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_class
     : public integral_constant<bool, __is_class(_Tp)> {};
 
-#else
-
-namespace __is_class_imp
-{
-template <class _Tp> true_type  __test(int _Tp::*);
-template <class _Tp> false_type __test(...);
-}
-
-template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_class
-    : public integral_constant<bool, decltype(__is_class_imp::__test<_Tp>(0))::value && !is_union<_Tp>::value> {};
-
-#endif
-
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
-inline constexpr bool is_class_v = is_class<_Tp>::value;
+inline constexpr bool is_class_v = __is_class(_Tp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_CLASS_H

libcxx/include/__type_traits/is_compound.h

 #include <__type_traits/is_fundamental.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// >= 11 because in C++03 nullptr isn't actually nullptr
-#if __has_keyword(__is_compound) && !defined(_LIBCPP_CXX03_LANG)
+#if __has_keyword(__is_compound)
 
 template<class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_compound : _BoolConstant<__is_compound(_Tp)> { };
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_compound_v = __is_compound(_Tp);
 #endif

libcxx/include/__type_traits/is_empty.h

 #include <__type_traits/integral_constant.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#if __has_feature(is_empty) || defined(_LIBCPP_COMPILER_GCC)
-
 template <class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_empty
     : public integral_constant<bool, __is_empty(_Tp)> {};
 
-#else  // __has_feature(is_empty)
-
-template <class _Tp>
-struct __is_empty1
-    : public _Tp
-{
-    double __lx;
-};
-
-struct __is_empty2
-{
-    double __lx;
-};
-
-template <class _Tp, bool = is_class<_Tp>::value>
-struct __libcpp_empty : public integral_constant<bool, sizeof(__is_empty1<_Tp>) == sizeof(__is_empty2)> {};
-
-template <class _Tp> struct __libcpp_empty<_Tp, false> : public false_type {};
-
-template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_empty : public __libcpp_empty<_Tp> {};
-
-#endif // __has_feature(is_empty)
-
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
-inline constexpr bool is_empty_v = is_empty<_Tp>::value;
+inline constexpr bool is_empty_v = __is_empty(_Tp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_EMPTY_H

libcxx/include/__type_traits/is_enum.h

 #include <__type_traits/remove_cv.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#if __has_feature(is_enum) || defined(_LIBCPP_COMPILER_GCC)
-
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_enum
     : public integral_constant<bool, __is_enum(_Tp)> {};
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_enum_v = __is_enum(_Tp);
 #endif
 
-#else
-
-template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_enum
-    : public integral_constant<bool, !is_void<_Tp>::value             &&
-                                     !is_integral<_Tp>::value         &&
-                                     !is_floating_point<_Tp>::value   &&
-                                     !is_array<_Tp>::value            &&
-                                     !is_pointer<_Tp>::value          &&
-                                     !is_reference<_Tp>::value        &&
-                                     !is_member_pointer<_Tp>::value   &&
-                                     !is_union<_Tp>::value            &&
-                                     !is_class<_Tp>::value            &&
-                                     !is_function<_Tp>::value         > {};
-
-#if _LIBCPP_STD_VER > 14
-template <class _Tp>
-inline constexpr bool is_enum_v = is_enum<_Tp>::value;
-#endif
-
-#endif // __has_feature(is_enum) || defined(_LIBCPP_COMPILER_GCC)
-
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_ENUM_H

libcxx/include/__type_traits/is_final.h

 
 #if _LIBCPP_STD_VER > 11
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS
 is_final : public integral_constant<bool, __is_final(_Tp)> {};
 #endif
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
-inline constexpr bool is_final_v = is_final<_Tp>::value;
+inline constexpr bool is_final_v = __is_final(_Tp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_FINAL_H

libcxx/include/__type_traits/is_function.h

 #include <__type_traits/is_reference.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_function
-    : public _BoolConstant<
-#ifdef __clang__
-    __is_function(_Tp)
+#if __has_keyword(__is_function)
+
+template <class _Tp>
+struct _LIBCPP_TEMPLATE_VIS is_function : integral_constant<bool, __is_function(_Tp)> {};
+
 #else
- !(is_reference<_Tp>::value || is_const<const _Tp>::value)
-#endif
-    > {};
 
+template <class _Tp>
+struct _LIBCPP_TEMPLATE_VIS is_function
+    : public integral_constant<bool, !(is_reference<_Tp>::value || is_const<const _Tp>::value)> {};
+
+#endif // __has_keyword(__is_function)
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_function_v = is_function<_Tp>::value;
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_FUNCTIONAL_H

libcxx/include/__type_traits/is_fundamental.h

 #include <__type_traits/is_null_pointer.h>
 #include <__type_traits/is_void.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// Before Clang 10, __is_fundamental didn't work for nullptr_t.
-// In C++03 nullptr_t is library-provided but must still count as "fundamental."
-#if __has_keyword(__is_fundamental) &&                                         \
-    !(defined(_LIBCPP_CLANG_VER) && _LIBCPP_CLANG_VER < 1000) &&               \
-    !defined(_LIBCPP_CXX03_LANG)
+#if __has_keyword(__is_fundamental)
 
 template<class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_fundamental : _BoolConstant<__is_fundamental(_Tp)> { };
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_fundamental_v = __is_fundamental(_Tp);
 #endif

libcxx/include/__type_traits/is_pointer.h

 #include <__type_traits/remove_cv.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// Before AppleClang 12.0.5, __is_pointer didn't work for Objective-C types.
-#if __has_keyword(__is_pointer) &&                                             \
-    !(defined(_LIBCPP_APPLE_CLANG_VER) && _LIBCPP_APPLE_CLANG_VER < 1205)
+#if __has_keyword(__is_pointer)
 
 template<class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_pointer : _BoolConstant<__is_pointer(_Tp)> { };
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_pointer_v = __is_pointer(_Tp);
 #endif

libcxx/include/__type_traits/is_scalar.h

 #include <__type_traits/is_pointer.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// In C++03 nullptr_t is library-provided but must still count as "scalar."
-#if __has_keyword(__is_scalar) && !defined(_LIBCPP_CXX03_LANG)
+#if __has_keyword(__is_scalar)
 
 template<class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_scalar : _BoolConstant<__is_scalar(_Tp)> { };
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_scalar_v = __is_scalar(_Tp);
 #endif

libcxx/include/__type_traits/is_union.h

 #include <__type_traits/remove_cv.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#if __has_feature(is_union) || defined(_LIBCPP_COMPILER_GCC)
-
 template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_union
     : public integral_constant<bool, __is_union(_Tp)> {};
 
-#else
-
-template <class _Tp> struct __libcpp_union : public false_type {};
-template <class _Tp> struct _LIBCPP_TEMPLATE_VIS is_union
-    : public __libcpp_union<typename remove_cv<_Tp>::type> {};
-
-#endif
-
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
-inline constexpr bool is_union_v = is_union<_Tp>::value;
+inline constexpr bool is_union_v = __is_union(_Tp);
 #endif
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP___TYPE_TRAITS_IS_UNION_H

libcxx/include/__type_traits/is_unsigned.h

 #include <__type_traits/is_arithmetic.h>
 #include <__type_traits/is_integral.h>
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-// Before Clang 13, __is_unsigned returned true for enums with signed underlying type.
-// No currently-released version of AppleClang contains the fixed intrinsic.
-#if __has_keyword(__is_unsigned) &&                                            \
-    !(defined(_LIBCPP_CLANG_VER) && _LIBCPP_CLANG_VER < 1300) &&               \
-    !defined(_LIBCPP_APPLE_CLANG_VER)
+// Before AppleClang 14, __is_unsigned returned true for enums with signed underlying type.
+#if __has_keyword(__is_unsigned) && !(defined(_LIBCPP_APPLE_CLANG_VER) && _LIBCPP_APPLE_CLANG_VER < 1400)
 
 template<class _Tp>
 struct _LIBCPP_TEMPLATE_VIS is_unsigned : _BoolConstant<__is_unsigned(_Tp)> { };
 
 #if _LIBCPP_STD_VER > 14
 template <class _Tp>
 inline constexpr bool is_unsigned_v = __is_unsigned(_Tp);
 #endif