This is an archive of the discontinued LLVM Phabricator instance.

[libc++][NFC] Rename basic_istream_view::__iterator to __basic_istream_view_iterator
ClosedPublic

Authored by philnik on Dec 27 2022, 5:56 PM.

Details

Summary

This makes it a lot easier to specialize traits types for it, like __segmented_iterator_traits.

Diff Detail

Event Timeline

philnik created this revision.Dec 27 2022, 5:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 27 2022, 5:56 PM
philnik requested review of this revision.Dec 27 2022, 5:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 27 2022, 5:56 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik retitled this revision from [libc++][NFC] Move rename baisc_istream_view::__iterator to __basic_istream_view_iterator to [libc++][NFC] Rename basic_istream_view::__iterator to __basic_istream_view_iterator.Dec 28 2022, 5:40 AM
philnik edited the summary of this revision. (Show Details)
Mordante accepted this revision.Dec 28 2022, 8:47 AM

LGTM modulo one minor issue.

libcxx/include/__ranges/istream_view.h
41

Same for the definition.

This revision is now accepted and ready to land.Dec 28 2022, 8:47 AM
philnik added inline comments.Dec 30 2022, 5:29 AM
libcxx/include/__ranges/istream_view.h
41

What does this actually do and how can we test it? We use the macro quite a bit, but not in any consistent way AFAICT.

ldionne added inline comments.Jan 12 2023, 8:34 AM
libcxx/include/__ranges/istream_view.h
41

Looking at the documentation and the definition of the macro, it applies the __type_visibility__(default) attribute to the type. This gives the vtable and the RTTI of the type (if any) default visibility.

This type doesn't have a vtable. The only scenario I can see this mattering in would be if someone throws a __basic_istream_view_iterator from a dylib and tries to catch it from an executable that uses that dylib. If the RTTI doesn't have default visibility, the RTTI generated in the executable and the RTTI generated in the dylib won't be coalesced by the dynamic linker, so we'll end up with two copies of the RTTI in the process. This means that e.g. the type_info::name() address would differ depending on whether you're inside the dylib or the executable, etc. Since some ABIs (the Itanium ABI) assume that the RTTI is unique within the process, this could lead to a situation where you are e.g. incapable of catching the object that was thrown from the dylib, since from the runtime's perspective they would be different types. See the Unique implementation of RTTI inside libcxx/include/typeinfo.

Caveat: This is kinda complicated and I'm just trying to work out the implications of this macro right now. TBH I've always found our visibility macros to be overcomplicated and have had on my mind to refactor them. For now I'd suggest that it's acceptable to not use this macro on this type.

This revision was landed with ongoing or failed builds.Jan 12 2023, 9:30 AM
This revision was automatically updated to reflect the committed changes.