#ifdef __clang__ guard in AllocatorBase

Clang Frontend
#1

In Allocator.h, there are two static_asserts that are guarded by an #ifdef clang. What’s up with that? Shouldn’t non clang environments be able to do this? Surely there’s a better way to check for overloads?

The two static_asserts in question:

  /// \brief Allocate \a Size bytes of \a Alignment aligned memory. This method
  /// must be implemented by \c DerivedT.
  void *Allocate(size_t Size, size_t Alignment) {
#ifdef __clang__
    static_assert(static_cast<void *(AllocatorBase::*)(size_t, size_t)>(
                      &AllocatorBase::Allocate) !=
                      static_cast<void *(DerivedT::*)(size_t, size_t)>(
                          &DerivedT::Allocate),
                  "Class derives from AllocatorBase without implementing the "
                  "core Allocate(size_t, size_t) overload!");
#endif
    return static_cast<DerivedT *>(this)->Allocate(Size, Alignment);
  }
 
  /// \brief Deallocate \a Ptr to \a Size bytes of memory allocated by this
  /// allocator.
  void Deallocate(const void *Ptr, size_t Size) {
#ifdef __clang__
    static_assert(static_cast<void (AllocatorBase::*)(const void *, size_t)>(
                      &AllocatorBase::Deallocate) !=
                      static_cast<void (DerivedT::*)(const void *, size_t)>(
                          &DerivedT::Deallocate),
                  "Class derives from AllocatorBase without implementing the "
                  "core Deallocate(void *) overload!");
#endif
    return static_cast<DerivedT *>(this)->Deallocate(Ptr, Size);
  }
#2

possible that static_assert isn’t supported on some of the compilers we support, or didn’t at some point. I’d check the commit history and if the reason cited (if there is one) doesn’t apply anymore, just remove it.

#3

I would guess it’s the pointer to member, not the static_assert. MSVC has significant problems with casts from the address of a member function to a pointer-to-member type (either a type mismatch due to a calling convention attribute or a failure to resolve overloaded functions properly, I don’t remember). We do something similar to this in Clang’s RecursiveASTVisitor, and it took a number of iterations to find a form that all of our buildbots were happy with.