[do not merge] Implement P1144 trivially-relocatable for indirect and polymorphic

[Quuxplusone]

This is my take on #302, just to have a "clean copy." I would like it merged, but I expect it to be closed, per the discussion on #302 about not wanting to maintain the extra complexity. (My goal is just to record this branch history in a neat place for any posterity who want to play with it on Godbolt.)

I've added the same logic for polymorphic<T>. (#302 did it only for indirect<T>.)
While doing this, I noticed:

• Neither type has any unit tests for is_nothrow_move_constructible, !is_trivially_fooable, etc. I think such unit tests should be added.
• indirect<T> correctly uses allocator_traits<A>::pointer, but polymorphic<T> hard-codes cblock_t* instead of allocator_traits<A>::rebind_alloc<cblock_t>::pointer. This means polymorphic<T> isn't compatible with Boost.Interprocess offset_ptr allocators. I could work up such a PR if you're interested; but (next bullet)
• I'm not sure I understand all the various versions of polymorphic that seem to exist side-by-side right now.
• I see a lot of uses of XYZ_HAS_STD_OPTIONAL (invariably true in C++17 and later) in "indirect_test.cc" (requires C++20 or later); these could perhaps be removed, unless the plan is to backport indirect to C++14-or-earlier just like polymorphic was backported.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.67%. Comparing base (994f3cc) to head (74b7dd2).
Report is 83 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #345   +/-   ##
=======================================
  Coverage   98.67%   98.67%           
=======================================
  Files           7        7           
  Lines         605      605           
=======================================
  Hits          597      597           
  Misses          8        8           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Twon]

Added an issue to track adding further unit-test support: #347

[Twon]

Added an issue to track adding tests bases on offset_ptr to ensure allocator_traits<A>::pointer is correctly supported: #348

[Twon]

Regarding the comment on various versions of polymorphic...

I'm not sure I understand all the various versions of polymorphic that seem to exist side-by-side right now.

What can we do to make this clearer? Should a note be added to the readme on the different implementations?

Basically, there are 4 versions:

• C++20 implementation of polymorphic
• C++14/17 compatible implementation of polymorphic for backwards compatibility
• An implementation of polymorphic using the small buffer optimisation
• An implementation of polymorphic using inline vtable

The 2 versions in experimentation were provided because questions we made about whether either of these approaches should be preferred during discussion of the designs at LEWG. The intention in supporting these is the design space is fully explored.

Please let me know if you have any questions or if there are any actions we can take to better document the purpose of supporting these.

[Quuxplusone]

@jbcoe @Twon fyi, llvm/llvm-project#84621 is in review right now, to implement __is_trivially_relocatable(T) in Clang in a way that conforms to P1144 and is suitable for use in std::is_trivially_relocatable_v as used in this patch. (No attribute yet, but that might be coming next, at which point this patch would be completely implementable in mainline Clang!) I know trivial relocation is just a very small tangent to this repo in general; but I'd love it if you were interested enough to visit that PR and say "yeah this would be useful for our purposes" or "no it wouldn't."

[jbcoe]

Closing as P1144 is not the direction chosen by the C++ standards committee.