[libc++] Add utilites for instantiating functions with multiple types

[philnik]

Summary

We currently call a lot of functions with the same list of types. To avoid forgetting any of them, this patch adds type_lists and utilities for it. Specifically, it adds

• type_list - This is just a list of types
• concatenate - This allows concatenating type_lists
• for_each - Iterate over a type_list

[philnik]

Try to fix CI

[philnik]

Try to fix CI

[EricWF]

I don't think the test suite is the place to get clever with code deduplication and template magic.

Readability is significantly more important than repeating yourself. Tests need to be correct upon inspection, because we don't have tests for our tests.
Also I imagine this significantly borks any diagnostics you might get when the test fails.

Tests are not the place to be clever.

[huixie90]

In D137476#3910815, @EricWF wrote:

I don't think the test suite is the place to get clever with code deduplication and template magic.

Readability is significantly more important than repeating yourself. Tests need to be correct upon inspection, because we don't have tests for our tests.
Also I imagine this significantly borks any diagnostics you might get when the test fails.

Tests are not the place to be clever.

I agree with this and readability is more important. But in certain scenarios, e.g the math tests refactoring Nicolas did which increases the coverage for math tests, it was really hard for me to figure out what types are missing in the original tests as the original tests have hundreds of lines that enumerates all the types it is testing, for every argument, which in my opinion, not very readable. I also think this utility is needed for 3 iterator arguments range algorithms tests , as enumerate the combinations of types make the tests not very readable and hard to spot any combination missing. I think it is a useful tool but requires careful testing of itself

[philnik]

In D137476#3913144, @huixie90 wrote:

In D137476#3910815, @EricWF wrote:

I don't think the test suite is the place to get clever with code deduplication and template magic.

Readability is significantly more important than repeating yourself. Tests need to be correct upon inspection, because we don't have tests for our tests.
Also I imagine this significantly borks any diagnostics you might get when the test fails.

Tests are not the place to be clever.

I agree with this and readability is more important. But in certain scenarios, e.g the math tests refactoring Nicolas did which increases the coverage for math tests, it was really hard for me to figure out what types are missing in the original tests as the original tests have hundreds of lines that enumerates all the types it is testing, for every argument, which in my opinion, not very readable. I also think this utility is needed for 3 iterator arguments range algorithms tests , as enumerate the combinations of types make the tests not very readable and hard to spot any combination missing. I think it is a useful tool but requires careful testing of itself

I agree that tests should be readable. I also agree that the test suite normally isn't the place for template magic. In this case I think the additional complexity is warranted, since it avoids forgetting anything in a list of types that are used commonly throughout the test suite and/or are subject to change over time. This is the case for example for the ranges algorithm tests, where we (should) use specific sets of iterators everywhere. Having the set of types in a central location allows us to update all the tests without being able to forget any one test. The other case are fundamental sets of types, like integral types, which are subject to change over time (i.e. there were additional floating point types added in C++23(?)) and it's a lot harder to miss any tests when all the tests have a single source of truth. Another benefit is that IMO it's a lot easier to understand what you are testing when you say meta::apply_all(meta::integral_types{}, []<class T>() { test<T>(); }). It's instantly clear that you are instantiating the test for all integral types.

As for errors, it doesn't really make them worse. It's just two or three extra entries in the Note: instantiated from here list, which is already miles long in most cases.

I also agree that this magic should be well tested if we want to use it in the tests. If you think I'm missing any coverage I'm happy to add more tests.

This is a major change in our testing infrastructure and I think all the people actively working on libc++ should at least take note of the change (@Mordante @var-const @ldionne - did I forget anyone?).

[jloser]

In D137476#3913717, @philnik wrote:

In D137476#3913144, @huixie90 wrote:

In D137476#3910815, @EricWF wrote:

I don't think the test suite is the place to get clever with code deduplication and template magic.

Readability is significantly more important than repeating yourself. Tests need to be correct upon inspection, because we don't have tests for our tests.
Also I imagine this significantly borks any diagnostics you might get when the test fails.

Tests are not the place to be clever.

I agree with this and readability is more important. But in certain scenarios, e.g the math tests refactoring Nicolas did which increases the coverage for math tests, it was really hard for me to figure out what types are missing in the original tests as the original tests have hundreds of lines that enumerates all the types it is testing, for every argument, which in my opinion, not very readable. I also think this utility is needed for 3 iterator arguments range algorithms tests , as enumerate the combinations of types make the tests not very readable and hard to spot any combination missing. I think it is a useful tool but requires careful testing of itself

I agree that tests should be readable. I also agree that the test suite normally isn't the place for template magic. In this case I think the additional complexity is warranted, since it avoids forgetting anything in a list of types that are used commonly throughout the test suite and/or are subject to change over time. This is the case for example for the ranges algorithm tests, where we (should) use specific sets of iterators everywhere. Having the set of types in a central location allows us to update all the tests without being able to forget any one test. The other case are fundamental sets of types, like integral types, which are subject to change over time (i.e. there were additional floating point types added in C++23(?)) and it's a lot harder to miss any tests when all the tests have a single source of truth. Another benefit is that IMO it's a lot easier to understand what you are testing when you say meta::apply_all(meta::integral_types{}, []<class T>() { test<T>(); }). It's instantly clear that you are instantiating the test for all integral types.

As for errors, it doesn't really make them worse. It's just two or three extra entries in the Note: instantiated from here list, which is already miles long in most cases.

I also agree that this magic should be well tested if we want to use it in the tests. If you think I'm missing any coverage I'm happy to add more tests.

This is a major change in our testing infrastructure and I think all the people actively working on libc++ should at least take note of the change (@Mordante @var-const @ldionne - did I forget anyone?).

FWIW, I understand the concern around using template metaprogramming adding complexity to the test suite, but I also see the benefits here for easily identifying a family of types and running a test function over that type family. In short, I'm +1 for this.

[Mordante]

I too feel we should avoid being "too clever" in unit tests. They should be "considered correct" without trying to do template meta programming in your head. So I agree with @EricWF that some of these things are "too clever". Other parts are already done in other tests. I've seen "test all integral types" tests in older charconv tests. I think it would help to have generic code for "sets of these types". This would avoid typing these lists multiple times with the risk of forgetting a type.

So I like the general idea behind this patch, but we should restrain ourselves against going full template meta programming. I feel you went a bit too far, but I see several improvements too.

Note I didn't do an in depth review, mainly wanted to point out some examples.

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

104

For a unit test this feels too clever for me.

107

This is the kind of cleverness I think is good in unit tests. I still need to look what meta::cpp20_input_iterator_list exact contains, but I usually I won't care, since this is the "set of input iterators we care about". We've done this kind of thing before with "all signed integers".

I really like the consistent use of the namespace meta. Maybe we should do the same for existing test that do this kind of thing.

libcxx/test/std/language.support/support.limits/limits/is_specialized.pass.cpp

47–50

To me this is an improvement. It's clear we want to test all arithmetic types. If we start to support additional arithmetic types it's easy to see what breaks by changing one place. (C++23 will add more floating-point types.)

48

This actually a bug, it should not be available when TEST_HAS_NO_WIDE_CHARACTERS is defined.

libcxx/test/std/strings/basic.string/string.access/at.pass.cpp

79

I consider this an improvement too, here we improve the test coverage.

libcxx/test/support/type_algorithms.h

21

I like the amount of documentation.

135

signed char is a a signed integer type too.

152

This too look a bit clever. Here it's quite obvious, but in a different use-case it might be less obvious.

[philnik]

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

104

What exactly do you mean? Concatenating two cartesian products, the caretesian_product_t itself, or maybe something completely different?

libcxx/test/support/type_algorithms.h

135

Good catch!

152

I think in some cases it makes sense, since i.e. if we add another integral type, like __int256_t or something like that, we can't forget to add the unsigned version. The same reasoning applies to the proxy iterator lists. But I agree we should consider whether we use it.

[Mordante]

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

104

Mainly the cartesian_product_t. I'm not sure everybody knows what a Cartesian product is. Note that I'm perfectly fine with the Cartesian product in our benchmarks, there it's easy to observe what it does by looking at the output. Here there is not output. So the question is, are you sure the test is correct?

So here I feel writing out the code, using helper functions, makes it easier to understand what happens. Which makes it easier to validate whether the test is correct.

libcxx/test/support/type_algorithms.h

152

Yes so this is a bit the borderline for me. This can be used to avoid errors, but at other places it can make the code harder to understand. It depends on how obvious the effect to the transformation is.

So here I like it. Having well named arguments helps too :-)

[philnik]

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

104

I think most people reading libc++ tests know what a cartesian product is. Even if you don't know what it is, it's about as hard to find out as what a proxy_iterator is, which you also have to know to understand the test. Having the cartesion product spelled out also makes it easier to find out what the intention of the code is. You don't have to go through multiple functions to find out.

[ldionne]

In D137476#3910815, @EricWF wrote:

I don't think the test suite is the place to get clever with code deduplication and template magic.

I agree. At the same time, tests are also a place where duplication can lead to inconsistent coverage and maintainability issues, when there's as many tests as we have.

I think we need to walk a fine line and find the sweet spot between complexity-because-of-cleverness and complexity-because-of-duplication. After experimenting, we think that 90% of the bang can be achieved with just type_list and for_each, which seems really reasonable.

Readability is significantly more important than repeating yourself.

Again, I agree, however repetition is not necessarily the best way to make code readable. And as we've seen in this review, our tests were sometimes wrong because we had such duplication.

@philnik
I support this direction but I think we can simplify it by providing just for_each and type_list, at least at first. Let's start with that and see where that takes us.

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

98–99

@philnik and I just played around with this, wondering what things would look like if we had a typelist and a foreach-like utility. I think we could get most of the benefits in this patch without incurring to much complexity. This is what this test would look like:

meta::for_each(meta::forward_iterator_list<int*>{}, []<class Out>() {
  test_iterators<cpp20_input_iterator<int*>, Out>();
  test_iterators<ProxyIterator<cpp20_input_iterator<int*>>, Out>();

  meta::for_each(meta::forward_iterator_list<int*>{}, []<class In>() {
    test_iterators<In, Out>();
    test_iterators<In, Out, sized_sentinel<In>>();
    test_iterators<In, Out, sentinel_wrapper<In>>();

    test_iterators<ProxyIterator<In>, Out>();
    test_iterators<ProxyIterator<In>, Out, sized_sentinel<ProxyIterator<In>>>();
    test_iterators<ProxyIterator<In>, Out, sentinel_wrapper<ProxyIterator<In>>>();
  });
});

libcxx/test/std/strings/basic.string/string.access/at.pass.cpp

79

Yeah, I agree -- making it easier to test across wide ranges of types will often increase our coverage because we can easily test everything while still being a bit lazy.

libcxx/test/support/type_algorithms.h

17

I have been thinking about introducing a namespace for our tests utilities for a while. I would have nested this into that namespace.

But I really don't want to start bikeshedding that topic and the namespace name in this review, so I'm happy to go with that and then grep replace it when/if we decide to introduce a namespace for our test utilities.

22–26

This feels a bit loose to me. I would only concatenate type lists together, not arbitrary types.

Otherwise, this breaks "generic programming" (not that we would want to do that in the test suite, but I still think it illustrates why this is surprising). Instead, if we need that functionality, I would call it something like append<list, type>, but I'm not sure we actually need that.

After our experiment, I think we agreed that concatenate and even cartesian_product can go away, at least for now.

51

I don't think that's needed anymore if we don't have cartesian_product.

53–57

How about this? I think it mirrors more closely what it does. It also removes the possibility for confusion between apply and apply_all.

91

I think we're walking a super tight line here. I would suggest removing this helper (even though that will increase duplication a bit when defining the lists below) to avoid opening the door too widely to arbitrary metaprogramming.

131

This seems to be >= C++11, and also char32_t.

[philnik]

Address commments

[philnik]

@Mordante I think all of your concerns have been addressed now. It would be great if you could comment again whether there is anything you don't like about the current state.
@var-const It would be nice if you could also take a look - you're the only regular contributor that didn't approve the general direction yet (also post-commit in case I land this before you have time to comment).

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

107

I think we're all on the same page about adding a namespace for our test utilities. I'll look into adding that. The main problem is probably to find a good name for it, since test is already used everywhere.

libcxx/test/support/type_algorithms.h

22–26

I agreed, but after looking again at the standard I think it makes sense to keep the type_list-concatenating parts. Specifically, intergal types, floating-point types and arithmetic types are specified in terms of other groups of types. I think it makes sense to follow the wording of the standard in code to make it trivial to verify. For example, arithmetic types is specified like this: Integral and floating-point types are collectively termed arithmetic types.. Written in code it's using arithmetic_types = concatenate_t<integral_types, floating_point_types>;.

53–57

The apply argument doesn't apply (I'm not sorry) anymore, but for_each is definitely a better name.

[philnik]

Rebased

[philnik]

Rebase

[philnik]

Try to fix CI

[ldionne]

libcxx/test/support/test_iterators.h

1302–1314

For a second I thought T was the value_type.

libcxx/test/support/type_algorithms.h

22–26

Ok, agreed.

[var-const]

@philnik Sorry about the delay! I think I like the general direction. I do share some of the concerns re. complexity raised in the review -- there's definitely a tradeoff there -- but I also feel that verbosity and duplication are the biggest bane of our test suite. Especially with some of the simplifications made, this looks really nice and IMO doesn't add that much complexity compared to the amount of error-prone boilerplate that it removes. I haven't looked at this in detail, but the general idea LGTM.

[var-const]

libcxx/test/support/test_iterators.h

1307

Question: why does bidirectional_iterator_list include random access iterators? From the name, I would expect it to be _at most_ bidirectional.

[philnik]

libcxx/test/support/test_iterators.h

1307

I mean it the other way around, as-in "everything that is a bidirectional_iterator", like we need for the algorithm tests - bidirectional and everything better.

[var-const]

libcxx/test/support/test_iterators.h

1307

Ah, makes sense. Thanks for explaining.

libcxx/test/std/algorithms/alg.modifying.operations/alg.copy/ranges.copy.pass.cpp

 
 #include <algorithm>
 #include <array>
 #include <cassert>
 #include <ranges>
 
 #include "almost_satisfies_types.h"
 #include "test_iterators.h"
+#include "type_algorithms.h"
 
 template <class In, class Out = In, class Sent = sentinel_wrapper<In>>
 concept HasCopyIt = requires(In in, Sent sent, Out out) { std::ranges::copy(in, sent, out); };
 
 static_assert(HasCopyIt<int*>);
 static_assert(!HasCopyIt<InputIteratorNotDerivedFrom>);
 static_assert(!HasCopyIt<InputIteratorNotIndirectlyReadable>);
 static_assert(!HasCopyIt<InputIteratorNotInputOrOutputIterator>);
constexpr void test_iterators() {
       auto range = std::ranges::subrange(In(in.data()), Sent(In(in.data() + in.size())));
       auto ret = std::ranges::copy(range, Out(out.data()));
       assert(base(ret.in) == in.data());
       assert(base(ret.out) == out.data());
     }
   }
 }
 
-template <class In, class Out>
-constexpr void test_sentinels() {
+constexpr bool test() {
+  meta::for_each(meta::forward_iterator_list<int*>{}, []<class Out>() {
+    test_iterators<cpp20_input_iterator<int*>, Out, sentinel_wrapper<cpp20_input_iterator<int*>>>();
+    test_iterators<ProxyIterator<cpp20_input_iterator<int*>>,
+                   ProxyIterator<Out>,
+                   sentinel_wrapper<ProxyIterator<cpp20_input_iterator<int*>>>>();
+
+    meta::for_each(meta::forward_iterator_list<int*>{}, []<class In>() {
       test_iterators<In, Out>();
       test_iterators<In, Out, sized_sentinel<In>>();
       test_iterators<In, Out, sentinel_wrapper<In>>();
-}
-
-template <class Out>
-constexpr void test_in_iterators() {
-  test_iterators<cpp20_input_iterator<int*>, Out, sentinel_wrapper<cpp20_input_iterator<int*>>>();
-  test_sentinels<forward_iterator<int*>, Out>();
-  test_sentinels<bidirectional_iterator<int*>, Out>();
-  test_sentinels<random_access_iterator<int*>, Out>();
-  test_sentinels<contiguous_iterator<int*>, Out>();
-}
 
-template <class Out>
-constexpr void test_proxy_in_iterators() {
-  test_iterators<ProxyIterator<cpp20_input_iterator<int*>>, Out, sentinel_wrapper<ProxyIterator<cpp20_input_iterator<int*>>>>();
-  test_iterators<ProxyIterator<forward_iterator<int*>>, Out>();
-  test_iterators<ProxyIterator<bidirectional_iterator<int*>>, Out>();
-  test_iterators<ProxyIterator<random_access_iterator<int*>>, Out>();
-  test_iterators<ProxyIterator<contiguous_iterator<int*>>, Out>();
-}
-
-constexpr bool test() {
-  test_in_iterators<cpp20_input_iterator<int*>>();
-  test_in_iterators<forward_iterator<int*>>();
-  test_in_iterators<bidirectional_iterator<int*>>();
-  test_in_iterators<random_access_iterator<int*>>();
-  test_in_iterators<contiguous_iterator<int*>>();
-
-  test_proxy_in_iterators<ProxyIterator<cpp20_input_iterator<int*>>>();
-  test_proxy_in_iterators<ProxyIterator<forward_iterator<int*>>>();
-  test_proxy_in_iterators<ProxyIterator<bidirectional_iterator<int*>>>();
-  test_proxy_in_iterators<ProxyIterator<random_access_iterator<int*>>>();
-  test_proxy_in_iterators<ProxyIterator<contiguous_iterator<int*>>>();
+      test_iterators<ProxyIterator<In>, ProxyIterator<Out>>();
+      test_iterators<ProxyIterator<In>, ProxyIterator<Out>, sized_sentinel<ProxyIterator<In>>>();
+      test_iterators<ProxyIterator<In>, ProxyIterator<Out>, sentinel_wrapper<ProxyIterator<In>>>();
+    });
+  });
 
   { // check that ranges::dangling is returned
     std::array<int, 4> out;
     std::same_as<std::ranges::in_out_result<std::ranges::dangling, int*>> auto ret =
-      std::ranges::copy(std::array {1, 2, 3, 4}, out.data());
+        std::ranges::copy(std::array{1, 2, 3, 4}, out.data());
     assert(ret.out == out.data() + 4);
     assert((out == std::array{1, 2, 3, 4}));
   }
 
   { // check that an iterator is returned with a borrowing range
     std::array in {1, 2, 3, 4};
     std::array<int, 4> out;
     std::same_as<std::ranges::in_out_result<int*, int*>> auto ret = std::ranges::copy(std::views::all(in), out.data());

libcxx/test/std/language.support/support.limits/limits/is_specialized.pass.cpp

 // -qualified type cv T shall be equal to the value of the corresponding
 // member of the specialization on the unqualified type T.
 
 // More convenient to test it here.
 
 #include <limits>
 #include <complex>
 
-#include "test_macros.h"
+#include "type_algorithms.h"
 
+struct Test {
   template <class T>
-void test()
-{
+  void operator()() {
     static_assert(std::numeric_limits<T>::is_specialized,
                  "std::numeric_limits<T>::is_specialized");
     static_assert(std::numeric_limits<const T>::is_specialized,
                  "std::numeric_limits<const T>::is_specialized");
     static_assert(std::numeric_limits<volatile T>::is_specialized,
                  "std::numeric_limits<volatile T>::is_specialized");
     static_assert(std::numeric_limits<const volatile T>::is_specialized,
                  "std::numeric_limits<const volatile T>::is_specialized");
   }
+};
 
 int main(int, char**)
 {
-    test<bool>();
-    test<char>();
-    test<wchar_t>();
-#if TEST_STD_VER > 17 && defined(__cpp_char8_t)
-    test<char8_t>();
-#endif
-    test<char16_t>();
-    test<char32_t>();
-    test<signed char>();
-    test<unsigned char>();
-    test<signed short>();
-    test<unsigned short>();
-    test<signed int>();
-    test<unsigned int>();
-    test<signed long>();
-    test<unsigned long>();
-    test<signed long long>();
-    test<unsigned long long>();
-#ifndef TEST_HAS_NO_INT128
-    test<__int128_t>();
-    test<__uint128_t>();
-#endif
-    test<float>();
-    test<double>();
-    test<long double>();
-    static_assert(!std::numeric_limits<std::complex<double> >::is_specialized,
-                 "!std::numeric_limits<std::complex<double> >::is_specialized");
+  meta::for_each(meta::arithmetic_types(), Test());
+
 
   return 0;
 }

libcxx/test/std/strings/basic.string/string.access/at.pass.cpp

 //       reference at(size_type pos); // constexpr since C++20
 
 #include <string>
 #include <stdexcept>
 #include <cassert>
 
 #include "min_allocator.h"
 
+#include "make_string.h"
 #include "test_macros.h"
+#include "type_algorithms.h"
 
 template <class S>
 TEST_CONSTEXPR_CXX20 void
 test(S s, typename S::size_type pos)
 {
     const S& cs = s;
     if (pos < s.size())
     {
else if (!TEST_IS_CONSTANT_EVALUATED)
         }
     }
 #endif
 }
 
 template <class S>
 TEST_CONSTEXPR_CXX20 void test_string() {
   test(S(), 0);
-  test(S("123"), 0);
-  test(S("123"), 1);
-  test(S("123"), 2);
-  test(S("123"), 3);
+  test(S(MAKE_CSTRING(typename S::value_type, "123")), 0);
+  test(S(MAKE_CSTRING(typename S::value_type, "123")), 1);
+  test(S(MAKE_CSTRING(typename S::value_type, "123")), 2);
+  test(S(MAKE_CSTRING(typename S::value_type, "123")), 3);
 }
 
-TEST_CONSTEXPR_CXX20 bool test() {
-  test_string<std::string>();
+struct TestCaller {
+  template <class T>
+  TEST_CONSTEXPR_CXX20 void operator()() {
+        test_string<std::basic_string<T> >();
 #if TEST_STD_VER >= 11
-  test_string<std::basic_string<char, std::char_traits<char>, min_allocator<char>>>();
+        test_string<std::basic_string<T, std::char_traits<T>, min_allocator<T> > >();
 #endif
+  }
+};
+
+TEST_CONSTEXPR_CXX20 bool test() {
+  meta::for_each(meta::character_types(), TestCaller());
 
   return true;
 }
 
 int main(int, char**)
 {
   test();
 #if TEST_STD_VER > 17
   static_assert(test());
 #endif
 
   return 0;
 }

libcxx/test/support/test.support/type_algorithms.pass.cpp

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include <algorithm>
+#include <cassert>
+#include <type_traits>
+
+#include "test_macros.h"
+#include "type_algorithms.h"
+
+// concatenate
+static_assert(std::is_same<meta::concatenate_t<meta::type_list<> >, meta::type_list<> >::value, "");
+static_assert(std::is_same<meta::concatenate_t<meta::type_list<int> >, meta::type_list<int> >::value, "");
+static_assert(
+    std::is_same<meta::concatenate_t<meta::type_list<int>, meta::type_list<long> >, meta::type_list<int, long> >::value,
+    "");
+static_assert(
+    std::is_same<meta::concatenate_t<meta::type_list<int>, meta::type_list<long>, meta::type_list<long long> >,
+                 meta::type_list<int, long, long long> >::value,
+    "");
+
+// apply_all
+template <int N>
+class NumT {};
+
+struct ApplyAllTest {
+  bool* is_called_array_;
+
+  TEST_CONSTEXPR ApplyAllTest(bool* is_called_array) : is_called_array_(is_called_array) {}
+
+  template <int N>
+  TEST_CONSTEXPR_CXX20 void check_num(NumT<N>) {
+    assert(!is_called_array_[N]);
+    is_called_array_[N] = true;
+  }
+
+  template <int N, int M>
+  TEST_CONSTEXPR_CXX20 void check_num(NumT<N>, NumT<M>) {
+    assert(!is_called_array_[N + M]);
+    is_called_array_[N + M] = true;
+  }
+
+  template <class... Types>
+  TEST_CONSTEXPR_CXX20 void operator()() {
+    check_num(Types()...);
+  }
+};
+
+struct Identity {
+  TEST_CONSTEXPR bool operator()(bool b) const { return b; }
+};
+
+TEST_CONSTEXPR_CXX20 void test_for_each() {
+  bool is_called_array[3] = {};
+  meta::for_each(meta::type_list<NumT<0>, NumT<1>, NumT<2> >(), ApplyAllTest(is_called_array));
+  assert(std::all_of(is_called_array, is_called_array + 3, Identity()));
+}
+
+TEST_CONSTEXPR_CXX20 bool test() {
+  test_for_each();
+  return true;
+}
+
+int main(int, char**) {
+  test();
+#if TEST_STD_VER >= 20
+  static_assert(test());
+#endif
+
+  return 0;
+}

libcxx/test/support/test_iterators.h

 #include <concepts>
 #include <iterator>
 #include <ranges>
 #include <stdexcept>
 #include <type_traits>
 #include <utility>
 
 #include "test_macros.h"
+#include "type_algorithms.h"
 
 
 // This iterator meets C++20's Cpp17OutputIterator requirements, as described
 // in Table 90 ([output.iterators]).
 template <class It>
 class cpp17_output_iterator
 {
     It it_;
constexpr auto end() const
     return ProxySentinel{std::ranges::end(base_)};
   }
 };
 
 template <std::ranges::input_range R>
   requires std::ranges::viewable_range<R&&>
 ProxyRange(R&&) -> ProxyRange<std::views::all_t<R&&>>;
 
+namespace meta {
+template <class Ptr>
+using random_access_iterator_list = type_list<Ptr, contiguous_iterator<Ptr>, random_access_iterator<Ptr>>;
+
+template <class Ptr>
+using bidirectional_iterator_list =
+    concatenate_t<random_access_iterator_list<Ptr>, type_list<bidirectional_iterator<Ptr>>>;
+
+template <class Ptr>
+using forward_iterator_list = concatenate_t<bidirectional_iterator_list<Ptr>, type_list<forward_iterator<Ptr>>>;
+
+template <class Ptr>
+using cpp20_input_iterator_list =
+    concatenate_t<forward_iterator_list<Ptr>, type_list<cpp20_input_iterator<Ptr>, cpp17_input_iterator<Ptr>>>;
+
+} // namespace meta
+
 #endif // TEST_STD_VER > 17
 
 #endif // SUPPORT_TEST_ITERATORS_H

libcxx/test/support/type_algorithms.h

+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef TEST_SUPPORT_TYPE_ALGORITHMS_H
+#define TEST_SUPPORT_TYPE_ALGORITHMS_H
+
+#include <type_traits>
+
+#include "test_macros.h"
+
+namespace meta {
+template <class... Types>
+struct type_list {};
+
+// concatenates N type_lists to one (for N >= 1)
+template <class...>
+struct concatenate;
+
+template <class... Types>
+using concatenate_t = typename concatenate<Types...>::type;
+
+// for_each takes a type_list calls f with each element as the first template argument
+template <class... Types, class Functor>
+TEST_CONSTEXPR_CXX14 void for_each(type_list<Types...>, Functor f);
+
+// impl
+template <class... Types>
+struct concatenate<type_list<Types...> > {
+  using type = type_list<Types...>;
+};
+
+template <class... Types1, class... Types2>
+struct concatenate<type_list<Types1...>, type_list<Types2...> > {
+  using type = type_list<Types1..., Types2...>;
+};
+
+template <class... Types1, class... Types2, class... Rest>
+struct concatenate<type_list<Types1...>, type_list<Types2...>, Rest...> {
+  using type = concatenate_t<type_list<Types1..., Types2...>, Rest...>;
+};
+
+template <class... Types>
+TEST_CONSTEXPR_CXX14 void swallow(Types...) {}
+
+template <class... Types, class Functor>
+TEST_CONSTEXPR_CXX14 void for_each(type_list<Types...>, Functor f) {
+  swallow((f.template operator()<Types>(), 0)...);
+}
+
+// type categories defined in [basic.fundamental] plus extensions (without CV-qualifiers)
+
+using character_types =
+    type_list<char
+#ifndef TEST_HAS_NO_WIDE_CHARACTERS
+              ,
+              wchar_t
+#endif
+#ifndef TEST_HAS_NO_CHAR8_T
+              ,
+              char8_t
+#endif
+#if TEST_STD_VER >= 11
+              ,
+              char16_t,
+              char32_t
+#endif
+              >;
+
+using signed_integer_types =
+    type_list<signed char,
+              short,
+              int,
+              long,
+              long long
+#ifndef TEST_HAS_NO_INT128
+              ,
+              __int128_t
+#endif
+              >;
+
+using unsigned_integer_types =
+    type_list<unsigned char,
+              unsigned short,
+              unsigned int,
+              unsigned long,
+              unsigned long long
+#ifndef TEST_HAS_NO_INT128
+              ,
+              __uint128_t
+#endif
+              >;
+
+using integral_types = concatenate_t<character_types, signed_integer_types, unsigned_integer_types, type_list<bool> >;
+
+using floating_point_types = type_list<float, double, long double>;
+
+using arithmetic_types = concatenate_t<integral_types, floating_point_types>;
+} // namespace meta
+
+#endif // TEST_SUPPORT_TYPE_ALGORITHMS_H