Add C++ concept for PAL

This will not be used unless the C++ standard version is raised to 20.  As
concepts and C++20 more generally are quite new, this does not do so.
Nevertheless, the use of concepts can improve the local development experience
as type mismatches are discovered earlier (at template invocation rather than
only during expansion).

CMakeLists.txt

@@ -71,6 +71,9 @@ macro(clangformat_targets)
   else ()
     message(STATUS "Generating clangformat target using ${CLANG_FORMAT}")
     file(GLOB_RECURSE ALL_SOURCE_FILES *.cc *.h *.hh)
+    # clangformat does not yet understand concepts well; for the moment, don't
+    # ask it to format them.  See https://reviews.llvm.org/D79773
+    list(FILTER ALL_SOURCE_FILES EXCLUDE REGEX "src/pal/pal_concept\.h$")
     add_custom_target(
       clangformat
       COMMAND ${CLANG_FORMAT}

src/ds/concept.h

@@ -0,0 +1,40 @@
+#pragma once
+
+/**
+ * C++20 concepts are referenced as if they were types in declarations within
+ * template parameters (e.g. "template<FooConcept Foo> ...").  That is, they
+ * take the place of the "typename"/"class" keyword on template parameters.
+ * If the compiler understands concepts, this macro expands as its argument;
+ * otherwise, it expands to the keyword "typename", so snmalloc templates that
+ * use concept-qualified parameters should use this to remain compatible across
+ * C++ versions: "template<SNMALLOC_CONCEPT(FooConcept) Foo>"
+ */
+#ifdef __cpp_concepts
+#  define SNMALLOC_CONCEPT(c) c
+#else
+#  define SNMALLOC_CONCEPT(c) typename
+#endif
+
+#ifdef __cpp_concepts
+namespace snmalloc
+{
+  /**
+   * C++20 concepts are more than just new syntax; there's a new support
+   * library specified as well.  As C++20 is quite new, however, there are some
+   * environments, notably Clang, that understand the syntax but do not yet
+   * offer the library.  Fortunately, alternate pronouciations are possible.
+   */
+#  ifdef _cpp_lib_concepts
+  /**
+   * ConceptSame<T,U> is true if T and U are the same type and false otherwise.
+   * When specifying a concept, use ConceptSame<U> to indicate that an
+   * expression must evaluate precisely to the type U.
+   */
+  template<typename T, typename U>
+  concept ConceptSame = std::same_as<T, U>;
+#  else
+  template<typename T, typename U>
+  concept ConceptSame = std::is_same<T, U>::value;
+#  endif
+} // namespace snmalloc
+#endif

src/mem/address_space.h

@@ -13,7 +13,7 @@ namespace snmalloc
    * It cannot unreserve memory, so this does not require the
    * usual complexity of a buddy allocator.
    */
-  template<typename PAL>
+  template<SNMALLOC_CONCEPT(ConceptPAL) PAL>
   class AddressSpaceManager : public PAL
   {
     /**

src/mem/largealloc.h

@@ -14,7 +14,7 @@
 
 namespace snmalloc
 {
-  template<class PAL>
+  template<SNMALLOC_CONCEPT(ConceptPAL) PAL>
   class MemoryProviderStateMixin;
 
   class Largeslab : public Baseslab
@@ -24,7 +24,7 @@ namespace snmalloc
   private:
     template<class a, Construction c>
     friend class MPMCStack;
-    template<class PAL>
+    template<SNMALLOC_CONCEPT(ConceptPAL) PAL>
     friend class MemoryProviderStateMixin;
     std::atomic<Largeslab*> next;
 
@@ -56,7 +56,7 @@ namespace snmalloc
   // This represents the state that the large allcoator needs to add to the
   // global state of the allocator.  This is currently stored in the memory
   // provider, so we add this in.
-  template<class PAL>
+  template<SNMALLOC_CONCEPT(ConceptPAL) PAL>
   class MemoryProviderStateMixin : public PalNotificationObject, public PAL
   {
     /**

src/mem/pool.h

@@ -2,6 +2,7 @@
 
 #include "../ds/flaglock.h"
 #include "../ds/mpmcstack.h"
+#include "../pal/pal_concept.h"
 #include "pooled.h"
 
 namespace snmalloc
@@ -21,7 +22,7 @@ namespace snmalloc
   {
   private:
     friend Pooled<T>;
-    template<typename TT>
+    template<SNMALLOC_CONCEPT(ConceptPAL) PAL>
     friend class MemoryProviderStateMixin;
 
     std::atomic_flag lock = ATOMIC_FLAG_INIT;

src/pal/pal.h

@@ -1,5 +1,7 @@
 #pragma once
 
+#include "../ds/concept.h"
+#include "pal_concept.h"
 #include "pal_consts.h"
 
 // If simultating OE, then we need the underlying platform
@@ -63,7 +65,7 @@ namespace snmalloc
   /**
    * Query whether the PAL supports a specific feature.
    */
-  template<PalFeatures F, typename PAL = Pal>
+  template<PalFeatures F, SNMALLOC_CONCEPT(ConceptPAL) PAL = Pal>
   constexpr static bool pal_supports = (PAL::pal_features & F) == F;
 
   // Used to keep Superslab metadata committed.

src/pal/pal_concept.h

@@ -0,0 +1,104 @@
+#pragma once
+
+#ifdef __cpp_concepts
+#  include "../ds/concept.h"
+#  include "pal_consts.h"
+
+#  include <utility>
+
+namespace snmalloc
+{
+  /**
+   * PALs must advertize the bit vector of their supported features and the
+   * platform's page size.  This concept enforces that these are indeed
+   * constants that fit in the desired types.  (This is subtly different from
+   * saying that they are the required types; C++ may handle constants without
+   * much regard for their claimed type.)
+   */
+  template<typename PAL>
+  concept ConceptPAL_static_members = requires()
+  {
+    typename std::integral_constant<uint64_t, PAL::pal_features>;
+    typename std::integral_constant<size_t, PAL::page_size>;
+  };
+
+  /**
+   * PALs expose an error reporting function which takes a const C string.
+   */
+  template<typename PAL>
+  concept ConceptPAL_error = requires(const char* const str)
+  {
+    { PAL::error(str) } -> ConceptSame<void>;
+  };
+
+  /**
+   * PALs expose a basic library of memory operations.
+   */
+  template<typename PAL>
+  concept ConceptPAL_memops = requires(PAL p, void* vp, size_t sz)
+  {
+    { p.notify_not_using(vp, sz) } noexcept -> ConceptSame<void>;
+
+    /* For reasons unknown, these seem to tickle some bug in MSVC */
+#  if !defined(_MSC_VER)
+    { p.template notify_using<NoZero>(vp, sz) } noexcept
+      -> ConceptSame<void>;
+    { p.template notify_using<YesZero>(vp, sz) } noexcept
+      -> ConceptSame<void>;
+#  endif
+
+    { p.template zero<false>(vp, sz) } noexcept -> ConceptSame<void>;
+    { p.template zero<true>(vp, sz) } noexcept -> ConceptSame<void>;
+  };
+
+  /**
+   * Absent any feature flags, the PAL must support a crude primitive allocator
+   */
+  template<typename PAL>
+  concept ConceptPAL_reserve_at_least = requires(PAL p, void* vp, size_t sz)
+  {
+    { p.reserve_at_least(sz) } noexcept
+      -> ConceptSame<std::pair<void*, size_t>>;
+  };
+
+  /**
+   * Some PALs expose a richer allocator which understands aligned allocations
+   */
+  template<typename PAL>
+  concept ConceptPAL_reserve_aligned = requires(PAL p, size_t sz)
+  {
+    { p.template reserve_aligned<false>(sz) } noexcept -> ConceptSame<void*>;
+    { p.template reserve_aligned<true>(sz) } noexcept -> ConceptSame<void*>;
+  };
+
+  /**
+   * Some PALs can provide memory pressure callbacks.
+   */
+  template<typename PAL>
+  concept ConceptPAL_mem_low_notify =
+    requires(PAL p, PalNotificationObject* pno)
+  {
+    { p.expensive_low_memory_check() } -> ConceptSame<bool>;
+    { p.register_for_low_memory_callback(pno) } -> ConceptSame<void>;
+  };
+
+  /**
+   * PALs ascribe to the conjunction of several concepts.  These are broken
+   * out by the shape of the requires() quantifiers required and by any
+   * requisite claimed pal_features.  PALs not claiming particular features
+   * are, naturally, not bound by the corresponding concept.
+   */
+  template<typename PAL>
+  concept ConceptPAL =
+    ConceptPAL_static_members<PAL> &&
+    ConceptPAL_error<PAL> &&
+    ConceptPAL_memops<PAL> &&
+    (!(PAL::pal_features & LowMemoryNotification) ||
+      ConceptPAL_mem_low_notify<PAL>) &&
+    (!!(PAL::pal_features & AlignedAllocation) ||
+      ConceptPAL_reserve_at_least<PAL>) &&
+    (!(PAL::pal_features & AlignedAllocation) ||
+      ConceptPAL_reserve_aligned<PAL>);
+
+} // namespace snmalloc
+#endif