This is an archive of the discontinued LLVM Phabricator instance.

[libcxx][ranges] Update `{front_,back_,}insert_iterator` for C++20.
AbandonedPublic

Authored by zoecarver on May 17 2021, 4:24 PM.

Details

Reviewers
cjdb
Quuxplusone
ldionne
Mordante
Group Reviewers
Restricted Project
Summary

Makes difference_type = std::ptrdiff_t and removes parent.

Diff Detail

Event Timeline

zoecarver requested review of this revision.May 17 2021, 4:24 PM
zoecarver created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2021, 4:24 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
This revision now requires changes to proceed.May 17 2021, 4:26 PM
cjdb added a comment.May 17 2021, 4:35 PM

This patch appears to conflict with D101729.

libcxx/include/iterator
770–776

It's an ABI break that I'm okay with (since I'm okay with all ABI breaks), but we should probably discuss this on the mailing list.

zoecarver added inline comments.May 17 2021, 5:09 PM
libcxx/include/iterator
770–776

Ah yes I forgot about that discussion. Would it be better to just add a dummy base class that we inherit from in ABI-stable mode after C++17?

libcxx/include/iterator
770–776

Would it be better to just add a dummy base class that we inherit from in ABI-stable mode

Yes, iff that base class is spelled iterator<output_iterator_tag, void, void, void, void>. Anything else would be an ABI break.
I tentatively suggest making an ABI flag for _LIBCPP_ABI_NO_EMPTY_BASES affecting all the obsolete empty bases; and rolling reverse_iterator's 2^n explosion into that flag as well. The reason I'm "tentative" is that I still don't understand what is the point of all these ABI flags —

  • who is the target audience who is expected to turn them on in production?
  • how do they control which flags they turn on?
  • how are these flags tested by the buildbots?

Thanks for working on this!

libcxx/include/iterator
770–776

I'm also in favour of adding an ABI flag.

  • Actually I don't expect a lot of customers using the unstable ABI. But we could discuss whether we make the unstable ABI ABI v2 and plan how to roll that out to our customers.
  • The customer can use the LIBCXX_ABI_UNSTABLE CMake flag to enable the unstable ABI, or define the individual flags manually.
  • The UBSAN build bot tests it. Recently I was considering to create a buildbot for it, but I noticed we already have one.
cjdb added inline comments.May 18 2021, 10:06 AM
libcxx/include/iterator
770–776

who is the target audience who is expected to turn them on in production?

🤷 Jason Turner noted that in his (relatively biased) survey on breaking ABI, no one seemed to flag that ABI stability was important to them, personally (link to video).

Perhaps we should survey our users and find out

  • how many of them genuinely care about ABI stability for projects they own
  • which C++ standard they're currently using
  • which version of LLVM they're currently using
  • when they plan to upgrade LLVM and which version they're planning to upgrade to
  • when they plan to move to a newer C++ standard and which they plan to move to

how do they control which flags they turn on?

I'd say that users who care about ABI stability should enable macros that they care about. Unlike the nodiscard discussion, ABI stability is something that should be opt-in, because it lets us conform to the latest standard while also preserving something that "users" supposedly care about.

Perhaps _LIBCPP_ABI_NO_CXX17_EMPTY_ITERATOR_BASE for this one, and _LIBCPP_ABI_NO_EMPTY_BASES as a general control mechanism for all the empty base deletions. We could also have _LIBCPP_NO_CXX17_ABI_BREAK (to be bikeshedded) that controls all _LIBCPP_ABI_NO_CXX17_* macros, in case users want to preserve stability with C++14. This idea is far from fleshed out, and deserves more discussion on Discord.

how are these flags tested by the buildbots?

I think we can do this with more fine grained macros and libcxx tests.

Mordante added inline comments.May 18 2021, 11:55 AM
libcxx/include/iterator
775

It seems the class also got a default constructor in C++20. Can you add _LIBCPP_INLINE_VISIBILITY constexpr back_insert_iterator() noexcept = default;?
Please also update the synopsis and front_insert_iterator? With these changes I can use the std::back_insert_iterator in std::format :-)

I think this can be closed now.

zoecarver abandoned this revision.Jun 1 2021, 9:18 AM