Fix the assumption in the propagate_const test about local layout
[folly.git] / folly / Portability.h
index da1fff85407fa09c4d8a25e19530aa6252c40194..b41893b59a017223bad2e590a8954495b945ad79 100644 (file)
@@ -17,7 +17,6 @@
 #pragma once
 
 #include <cstddef>
-#include <type_traits>
 
 #include <folly/portability/Config.h>
 
@@ -30,87 +29,11 @@ constexpr bool kHasUnalignedAccess = true;
 #else
 constexpr bool kHasUnalignedAccess = false;
 #endif
-
-namespace portability_detail {
-
-template <typename I, I A, I B>
-using integral_max = std::integral_constant<I, (A < B) ? B : A>;
-
-template <typename I, I A, I... Bs>
-struct integral_sequence_max
-    : integral_max<I, A, integral_sequence_max<I, Bs...>::value> {};
-
-template <typename I, I A>
-struct integral_sequence_max<I, A> : std::integral_constant<I, A> {};
-
-template <typename... Ts>
-using max_alignment = integral_sequence_max<size_t, alignof(Ts)...>;
-
-using max_basic_alignment = max_alignment<
-    std::max_align_t,
-    long double,
-    double,
-    float,
-    long long int,
-    long int,
-    int,
-    short int,
-    bool,
-    char,
-    char16_t,
-    char32_t,
-    wchar_t,
-    std::nullptr_t>;
-} // namespace portability_detail
-
-constexpr size_t max_align_v = portability_detail::max_basic_alignment::value;
-
-// max_align_t is a type which is aligned at least as strictly as the
-// most-aligned basic type (see the specification of std::max_align_t). This
-// implementation exists because 32-bit iOS platforms have a broken
-// std::max_align_t (see below).
-//
-// You should refer to this as `::folly::max_align_t` in portable code, even if
-// you have `using namespace folly;` because C11 defines a global namespace
-// `max_align_t` type.
-//
-// To be certain, we consider every non-void fundamental type specified by the
-// standard. On most platforms `long double` would be enough, but iOS 32-bit
-// has an 8-byte aligned `double` and `long long int` and a 4-byte aligned
-// `long double`.
-//
-// So far we've covered locals and other non-allocated storage, but we also need
-// confidence that allocated storage from `malloc`, `new`, etc will also be
-// suitable for objects with this alignment reuirement.
-//
-// Apple document that their implementation of malloc will issue 16-byte
-// granularity chunks for small allocations (large allocations are page-size
-// granularity and page-aligned). We think that allocated storage will be
-// suitable for these objects based on the following assumptions:
-//
-// 1. 16-byte granularity also means 16-byte aligned.
-// 2. `new` and other allocators follow the `malloc` rules.
-//
-// We also have some anecdotal evidence: we don't see lots of misaligned-storage
-// crashes on 32-bit iOS apps that use `double`.
-//
-// Apple's allocation reference: http://bit.ly/malloc-small
-struct alignas(max_align_v) max_align_t {};
-
 } // namespace folly
 
 // compiler specific attribute translation
 // msvc should come first, so if clang is in msvc mode it gets the right defines
 
-#if defined(__clang__) || defined(__GNUC__)
-# define FOLLY_ALIGNED(size) __attribute__((__aligned__(size)))
-#elif defined(_MSC_VER)
-# define FOLLY_ALIGNED(size) __declspec(align(size))
-#else
-# error Cannot define FOLLY_ALIGNED on this platform
-#endif
-#define FOLLY_ALIGNED_MAX FOLLY_ALIGNED(::folly::max_align_v)
-
 // NOTE: this will only do checking in msvc with versions that support /analyze
 #if _MSC_VER
 # ifdef _USE_ATTRIBUTES_FOR_SAL
@@ -166,6 +89,12 @@ struct alignas(max_align_v) max_align_t {};
 # define FOLLY_X64 0
 #endif
 
+#if defined(__arm__)
+#define FOLLY_ARM 1
+#else
+#define FOLLY_ARM 0
+#endif
+
 #if defined(__aarch64__)
 # define FOLLY_AARCH64 1
 #else
@@ -179,6 +108,7 @@ struct alignas(max_align_v) max_align_t {};
 #endif
 
 namespace folly {
+constexpr bool kIsArchArm = FOLLY_ARM == 1;
 constexpr bool kIsArchAmd64 = FOLLY_X64 == 1;
 constexpr bool kIsArchAArch64 = FOLLY_AARCH64 == 1;
 constexpr bool kIsArchPPC64 = FOLLY_PPC64 == 1;