[PATCH] D21718: [libcxx] [test] Make move_assign_noexcept.pass.cpp tests more portable.
Stephan T. Lavavej via cfe-commits
cfe-commits at lists.llvm.org
Fri Jun 24 18:40:53 PDT 2016
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.
Make move_assign_noexcept.pass.cpp tests more portable.
Note that the relevant wording here was modified by C++17 N4258 "Cleaning-up noexcept in the Library (Rev 3)", which MSVC has implemented exactly. You may wish to modify these tests to have 14/17 codepaths. I'm testing our STL as C++17.
First, this was static_asserting that the ordered/unordered associative containers, when templated on other_allocator, satisfy is_nothrow_move_assignable. However, that isn't guaranteed by N4594, where the move assigns are depicted as inspecting is_always_equal (and the Compare/Hash/Pred). other_allocator is stateful, and allocator_traits correctly reports is_always_equal as false. Therefore, these static_asserts should be marked as libc++ specific.
Second, this was static_asserting is_nothrow_move_assignable for vector<bool> (both plain and other_allocator). However, vector<bool>'s move assign isn't depicted with any amount of noexcept in the Working Paper, so these static_asserts are non-portable.
Third, deque/forward_list/list have move assigns in N4594 that are depicted as inspecting is_always_equal. The tests here were static_asserting is_nothrow_move_assignable for other_allocator, but (again) that's stateful, so is_always_equal is false.
Finally, the deque/forward_list/list tests were static_asserting !is_nothrow_move_assignable for some_alloc, which is stateless but with a potentially-throwing copy ctor. This is contrary to N4594, which says "hey, your some_alloc is stateless, so is_always_equal is true, so these containers are nothrow-move-assignable, because you're not allowed to actually emit exceptions from allocator copies/moves". I'm just marking these as LIBCPP_STATIC_ASSERT, but (like the noexcept dtor tests) I believe you actually have a product bug here, at least in C++17 mode.
Random aside: these some_alloc classes are bogus, because they aren't rebind-constructible, nor do they have equality/inequality. MSVC happens to accept this, for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9885 bytes
Desc: not available
More information about the cfe-commits