`new_delete_resource().allocate(n, a)` has basically threewo permissible results:
- Return an appropriately sized and aligned block.
- Throw bad_alloc.
- If `n == 0`, return an unspecified result. [EDIT: no idea where I got this from]
Before this patch, libc++'s `new_delete_resource` would do a fourththird and impermissible thing, which was to return an appropriately sized but inappropriately under-aligned block. This is now fixed.
(This came up while I was stress-testing `unsynchronized_pool_resource` on my MacBook. If we can't trust the default resource to return appropriately aligned blocks, pretty much everything breaks. For similar reasons, I would strongly support just patching `__libcpp_allocate` directly, but I don't care to die on that hill, so I made this patch as a `<memory_resource>`-specific workaround.)
Also, remove some incorrect `noexcept` from <memory_resource>. I noticed this because the calls to `__clang_call_terminate` showed up on Godbolt. But the pessimization is still there even without these `noexcept`! Basically the flow is this:
- polymorphic_allocator::destroy (noexcept(X) but inlineable)
- ~T (noexcept(true))
- polymorphic_allocator::deallocate (noexcept(X) but inlineable)
- memory_resource::deallocate (noexcept(false) and not inlineable)
where "X" is "true" before this patch and "false" afterward.
Even for `monotonic_buffer_resource`, we can't conclude that deallocation will never throw, because deallocation *might* involve the upstream resource, which we don't know anything about. This is unfortunate but also unfixable, AFAICT.