This is an archive of the discontinued LLVM Phabricator instance.

[libc++][NFCI] Remove unnecessary exception-throwing base classes
ClosedPublic

Authored by ldionne on Aug 19 2021, 9:19 AM.

Details

Summary

split_buffer_common was entirely unused, and deque_base_common
was unused except for two calls to __throw_out_of_range(), which have
been inlined.

The usual intent of the __xxx_base_common base classes is to localize
where the exception-throwing code is instantiated, however that wasn't
the case here because we never explicitly instantiated those base classes
in the shared library, unlike what we do for basic_string and vector.

Diff Detail

Event Timeline

ldionne requested review of this revision.Aug 19 2021, 9:19 AM
ldionne created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptAug 19 2021, 9:19 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone added a subscriber: Quuxplusone.
Quuxplusone added inline comments.
libcxx/include/deque
915–916

I notice these were never _LIBCPP_HIDE_FROM_ABI or whatever. But that's fine, right? I believe I agree that this PR doesn't cause an ABI break in any interesting sense.

libcxx/include/deque
1853

I spoke slightly too soon. You are gratuitously changing the what-message here, right? That's definitely not "NFCI", and I'm ambivalent as to whether it's a good idea. The old message is just the word "deque", which is not great, but it at least has the virtue of taking up not-too-many bytes of storage. Whereas adding "...index out of bounds" to an exception of type std::out_of_range really isn't adding anything useful, is it? The user should already know what "out of range" means.

I suggest doing the NFC part alone, and then following up with a non-NFC change from "deque" to "deque::at" — spending 4 bytes to get a bit more useful info, but not going further than that.

ldionne added inline comments.Aug 19 2021, 10:55 AM
libcxx/include/deque
1853

Hmm, I guess you're right - I'm fine with just keeping "deque" only.

ldionne updated this revision to Diff 367555.Aug 19 2021, 10:59 AM
ldionne marked 2 inline comments as done.

Address review comments.

libcxx/include/deque
915–916

Yes, that should be fine. Anyone using these functions had a weak-definition in their TU, which the linker deduped across TUs (based on the ODR). Now we're just removing those, so that new code compiled against the new headers won't need or generate those weak definitions. It would be a risk of ODR-violation if we changed the definition of these functions because existing code was compiled with one definition and new code would be compiled with a new definition, but that's not what we're doing here.

ldionne accepted this revision.Aug 19 2021, 10:59 AM
This revision is now accepted and ready to land.Aug 19 2021, 10:59 AM
This revision was landed with ongoing or failed builds.Aug 19 2021, 11:00 AM
This revision was automatically updated to reflect the committed changes.