[PATCH] D54814: Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`.

[Eric Fiselier via Phabricator]

EricWF added a comment.

After further thought I don't think this approach is strictly correct.

In D54814#1322110 <https://reviews.llvm.org/D54814#1322110>, @jyknight wrote:

> I'd note that most of this diff was not actually required to fix the issue. E.g, in the locations where an alignment is passed to allocation/deallocation functions directly, it is perfectly fine to use the __alignof value instead of the alignof value.
>
> We could also ameliorate some ABI breakage by continuing to use __alignof within libc++, where changing to alignof would break the ABI of a standard library type. E.g., we could switch the use of std::alignment_of in __any_imp to instead call __alignof, preserving behavior.


I see a couple different classes of use cases:

1. `std::alignment_of` which should obviously use `alignof`.
2. Allocation functions and friends (such as `__libcpp_allocate` and `__is_over_aligned_for_new`). These should use `alignof` so they dispatch to aligned operator new in the same cases where Clang would implicitly call it.
3. `aligned_storage` and `aligned_union`: I think it's better to keep these using the preferred alignment, especially considering that `aligned_storage_t<sizeof(max_align_t)>` would be under aligned if we didn't (Thanks to how GCC and Clang define `max_align_t`).
4. Manually aligned STL internals (such as in `std::array` or `std::any`). These should switch to use `alignof` (as if we had been using it all along). If this breaks users ABI's, they should use the Clang flag.

I think I'll iterate by introducing `_LIBCPP_PREFERRED_ALIGNOF` to service instances of (3) while using `_LIBCPP_ALIGNOF` for cases (1), (2), and (4).


Repository:
  rCXX libc++

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54814/new/

https://reviews.llvm.org/D54814