This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Implement P1165R1 (Make stateful allocator propagation more consistent)
ClosedPublic

Authored by philnik on Feb 7 2022, 12:36 AM.

Diff Detail

Event Timeline

philnik requested review of this revision.Feb 7 2022, 12:36 AM
philnik created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2022, 12:36 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik updated this revision to Diff 406345.Feb 7 2022, 12:57 AM
  • Don't use macros for constexpr

It would help to mention the paper's title "Make stateful allocator propagation more consistent", in the PR's topic line.

LGTM modulo test nits. The table in p1165r1 says libc++ needs to change in exactly 5 places, and I see exactly 5 places being changed here, so that seems good to me.

libcxx/include/string
4216–4218

Throughout, I'd prefer to see _String (or even _Self) instead of __string, to avoid confusion with std::string and <__string>. But maybe that's controversial, I'm not sure.

libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp
27–28

Nit: Since the first mention on the line is of T, I'd prefer if s/value_type/T/ on the second mention as well.

32

It would be slightly better if you could find a way to distinguish

returned_alloc = lhs_alloc.select_on_container_copy_construction();

from

(void) lhs_alloc.select_on_container_copy_construction();
returned_alloc = lhs_alloc;

i.e., your select_on_container_copy_construction should do something observably different from just making a straight copy. I'm not sure what that would be, though. Maybe here return soccc_allocator(soccc_count + 1)... but that seems too "cute/clever" to me. You might have to add a second data member for that purpose. It might not be worth the bother.

146

In tests, [[maybe_unused]] should be considered a code smell. Don't you need to assert(r.get_allocator().soccc_count == &soccc_rhs) afterward, i.e. the correct allocator got propagated? If you check every postcondition, [[maybe_unused]] should basically never be necessary.

philnik retitled this revision from [libc++] Implement P1165R1 to [libc++] Implement P1165R1 (Make stateful allocator propagation more consistent).Feb 7 2022, 12:22 PM
philnik updated this revision to Diff 406568.Feb 7 2022, 12:23 PM
philnik marked 4 inline comments as done.
  • Address comments

The get_soccc() getter may be overkill (versus just making those members public). Consider making the getters const-qualified. But LGTM!

We need to update the status page, and also please add a release note!

libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp
11

Add:

// This test ensures that we properly propagate allocators, per https://wg21.link/p1165r1
45

Can we template that on CharT and run the test for both char and wchar_t (if !defined(TEST_HAS_NO_WIDE_CHARACTERS))? The reason I'm asking is that we explicitly instantiate some string methods in the dylib for char, but not for wchar_t. We expect the behavior for char and wchar_t to be the same, however I could imagine a case where they don't match (for example in back-deployment cases for char, since operator+ is in the dylib). Adding wchar_t will help shake out these potential differences.

Incidentally, I don't understand why this test passes on Apple backdeployment, since I would expect it to use operator+ in the dylib, which doesn't do SOCCC properly.

ldionne requested changes to this revision.Feb 10 2022, 7:57 AM
ldionne added inline comments.
libcxx/include/string
4164–4167

Is there any reason why we don't implement those naively like in the Standard? I don't think there's any performance gain here, right? This applies to all the overloads AFAICT.

This revision now requires changes to proceed.Feb 10 2022, 7:57 AM
philnik updated this revision to Diff 407544.Feb 10 2022, 8:11 AM
philnik marked 2 inline comments as done.
  • Address comments
ldionne added inline comments.Feb 10 2022, 8:13 AM
libcxx/test/std/strings/basic.string/string.nonmembers/string_op+/allocator_propagation.pass.cpp
191

wchar_t

philnik updated this revision to Diff 407546.Feb 10 2022, 8:26 AM
philnik marked an inline comment as done.
  • Address comment
libcxx/include/string
4164–4167

IIUC this implementation makes only one allocation, while making a copy and appending makes two allocations.

ldionne accepted this revision.Feb 17 2022, 12:50 PM
ldionne added inline comments.
libcxx/include/string
4164–4167

Oh, right, because we already reserve enough space for the append to be allocation-free. Makes sense.

This revision is now accepted and ready to land.Feb 17 2022, 12:50 PM
This revision was landed with ongoing or failed builds.Feb 17 2022, 1:01 PM
This revision was automatically updated to reflect the committed changes.