From 2e47068db220fc9897ce8140e4dae5c11bb09f2c Mon Sep 17 00:00:00 2001 From: Aaron Jacobs Date: Tue, 11 Apr 2023 17:58:22 -0700 Subject: 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 --- absl/container/internal/inlined_vector.h | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) (limited to 'absl/container/internal/inlined_vector.h') diff --git a/absl/container/internal/inlined_vector.h b/absl/container/internal/inlined_vector.h index e38cd8b1..945129b9 100644 --- a/absl/container/internal/inlined_vector.h +++ b/absl/container/internal/inlined_vector.h @@ -306,20 +306,9 @@ class Storage { // 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 // individually move-assigned each value and then destroyed the original. - // - // TODO(b/274984172): we check for copy-assignability here only for - // historical reasons. This is too strict: we are simulating move - // 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>, - absl::is_trivially_destructible>, - std::is_same>>, - absl::is_trivially_copy_constructible>>::value, + absl::conjunction>, + absl::is_trivially_destructible>, + std::is_same>>>::value, MemcpyPolicy, // Otherwise we use move assignment if possible. If not, we simulate // move assignment using move construction. -- cgit v1.2.3