Commit 2e47068d by Aaron Jacobs Committed by Copybara-Service

inlined_vector: fix incorrect restrictions on the move-assignment fast path.

This has nothing to do with copy construction or copy assignment.

PiperOrigin-RevId: 523557887
Change-Id: I332d6ceaf738305157605f1271cb577a83d198c5
parent dd89c56c
...@@ -306,20 +306,9 @@ class Storage { ...@@ -306,20 +306,9 @@ class Storage {
// it's safe for us to simply adopt the contents of the storage for // it's safe for us to simply adopt the contents of the storage for
// `other` and remove its own reference to them. It's as if we had // `other` and remove its own reference to them. It's as if we had
// individually move-assigned each value and then destroyed the original. // individually move-assigned each value and then destroyed the original.
// absl::conjunction<absl::is_trivially_move_assignable<ValueType<A>>,
// TODO(b/274984172): we check for copy-assignability here only for absl::is_trivially_destructible<ValueType<A>>,
// historical reasons. This is too strict: we are simulating move std::is_same<A, std::allocator<ValueType<A>>>>::value,
// assignment here.
//
// TODO(b/274984172): the condition on copy-constructibility is here only
// for historical reasons. It doesn't make semantic sense: we don't need
// to be able to copy construct here, we are doing an "as-if" move
// assignment.
absl::conjunction<
absl::is_trivially_copy_assignable<ValueType<A>>,
absl::is_trivially_destructible<ValueType<A>>,
std::is_same<A, std::allocator<ValueType<A>>>,
absl::is_trivially_copy_constructible<ValueType<A>>>::value,
MemcpyPolicy, MemcpyPolicy,
// Otherwise we use move assignment if possible. If not, we simulate // Otherwise we use move assignment if possible. If not, we simulate
// move assignment using move construction. // move assignment using move construction.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment