Prepare the constexpr machinery needed for string and vector

[Michael Schellenberger Costa (miscco)]

This is a precursor for #1407 and #1502

The hope is that this can more easily flesh out the clang bugs

[Michael Schellenberger Costa (miscco)]

I rebased this upon the latest changes and included the mutable fix.

[Michael Schellenberger Costa (miscco)]

I believe we need a new define.

Once the next preview is out, we want to switch this around and activate all the machinery for MSVC only due to the clang bug that prevents construction of mutable subobjects during constant evaluation.

At the same time we should not deactivate the machinery for allocations during constant evalutions.

My proposal would be to move to _CONSTEXPR20_CONTAINER and use this going forward. Thoughts?!

[Miya Natsuhara (mnatsuhara)]

I think you're right. To recap the situation:
Once we can consume 16.9 Preview 3, we should (hopefully 🤞) be unblocked to implement constexpr std::string and std::vector, so _CONSTEXPR20_DYNALLOC should be set to constexpr as long as we are in C++20 mode (not restricted by any specific compiler), and inline otherwise.

However, even once we have the next preview, we will still be blocked for Clang by Bug 48606 so we want some new macro that will be constexpr if _HAS_CXX20 && defined(_MSC_VER), and inline otherwise.

The only way that we could use _CONSTEXPR20_DYNALLOC for the constexpr containers would be to relinquish Clang support for WG21-P0784, which does seem undesirable. We'll just need to be careful trying to juggle yet another constexpr-related macro! _CONSTEXPR20_CONTAINER seems fine to me.

[Miya Natsuhara (mnatsuhara)]

I did a full review of the changes, and I think we're in pretty good shape! Just a few small changes and one potential bug (in _Uninitialized_copy_unchecked)!

[Michael Schellenberger Costa (miscco)]

Awesome, thanks a lot!

[Stephan T. Lavavej (StephanTLavavej)]

This is blocked by DevCom-1328628 "SFINAE bug when a default argument is protected", encountered when mirroring this to the MSVC-internal repo. (Part of MSVC uses std::optional with RapidJSON - std::optional uses the constrained construct_at here, while RapidJSON contains the protected static const data member pattern.)

I may be able to prepare a workaround.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks for implementing this machinery and finding so many bugs in so many compilers! 😹 ⚙️ 🪲 🪲 🪲