b1983f4582
This fixes a regression due to the conditional noexcept-specifier on std::allocator::construct and std::allocator::destroy, as well as the corresponding members of new_allocator, malloc_allocator, and allocator_traits. Those noexcept-specifiers were using expressions which might be ill-formed, which caused errors outside the immediate context when checking for the presence of construct and destroy in SFINAE contexts. The fix is to use the is_nothrow_constructible and is_nothrow_destructible type traits instead, because those traits are safe to use even when the construction/destruction itself is not valid. The is_nothrow_constructible trait will be false for a type that is not also nothrow-destructible, even if the new-expression used in the construct function body is actually noexcept. That's not the correct answer, but isn't a problem because providing a noexcept-specifier on these functions is not required by the standard anyway. If the answer is false when it should be true, that's suboptimal but OK (unlike giving errors for valid code, or giving a true answer when it should be false). PR libstdc++/89510 * include/bits/alloc_traits.h (allocator_traits::_S_construct) (allocator_traits::_S_destroy) (allocator_traits<allocator<T>>::construct): Use traits in noexcept-specifiers. * include/bits/allocator.h (allocator<void>::construct) (allocator<void>::destroy): Likewise. * include/ext/malloc_allocator.h (malloc_allocator::construct) (malloc_allocator::destroy): Likewise. * include/ext/new_allocator.h (new_allocator::construct) (new_allocator::destroy): Likewise. * testsuite/20_util/allocator/89510.cc: New test. * testsuite/ext/malloc_allocator/89510.cc: New test. * testsuite/ext/new_allocator/89510.cc: New test. |
||
---|---|---|
.. | ||
requirements | ||
1.cc | ||
8230.cc | ||
10378.cc | ||
14176.cc | ||
33807.cc | ||
89510.cc | ||
overaligned.cc | ||
rebind_c++20.cc | ||
void.cc |