This is an archive of the discontinued LLVM Phabricator instance.

[libc++] __config cleanup; _LIBCPP_ABI_UNSTABLE should set _LIBCPP_ABI_VERSION
ClosedPublic

Authored by philnik on Feb 4 2022, 5:32 AM.

Details

Summary

Some __config cleanup and _LIBCPP_ABI_UNSTABLE should set _LIBCPP_ABI_VERSION, since the latest ABI version is the unstable ABI.

Diff Detail

Event Timeline

philnik requested review of this revision.Feb 4 2022, 5:32 AM
philnik created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2022, 5:32 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
Quuxplusone requested changes to this revision.Feb 4 2022, 9:32 AM

Requesting changes just to make sure this gets attention.
Skimming the existing code, it looks to me as if a vendor who compiles with -D_LIBCPP_ABI_UNSTABLE -U_LIBCPP_ABI_VERSION will currently get all their symbols in namespace std::__1. This PR changes that, so that they'll get all their symbols in namespace std::__2 instead. I suspect this is not something we want to do, but ABI/vendor issues are above my pay grade, so I don't want to say I'm objecting to this. Just calling out a change that I think is likely to be significant.

This revision now requires changes to proceed.Feb 4 2022, 9:32 AM

Requesting changes just to make sure this gets attention.
Skimming the existing code, it looks to me as if a vendor who compiles with -D_LIBCPP_ABI_UNSTABLE -U_LIBCPP_ABI_VERSION will currently get all their symbols in namespace std::__1. This PR changes that, so that they'll get all their symbols in namespace std::__2 instead. I suspect this is not something we want to do, but ABI/vendor issues are above my pay grade, so I don't want to say I'm objecting to this. Just calling out a change that I think is likely to be significant.

I think if you compile with _LIBCPP_ABI_UNSTABLE you shouldn't have a problem with ABI changes. That's the entire point of using this macro. I might be wrong, but that's how I understand it. @ldionne should be able to clarify. We can of course also ask #libc_vendors.

ldionne accepted this revision.Feb 4 2022, 1:35 PM

This looks correct to me. I've actually wanted to get rid of _LIBCPP_ABI_UNSTABLE for a while, and I guess this is a great occasion to do this. Indeed, since this is the unstable ABI, we don't care about the namespace changing. If someone comes to this patch and they are broken by it, then they just figured out that they shouldn't be on the unstable ABI.

I'm not a big fan of mixing changes like this in the same commit, I'd have rather made all the NFC cleanups in one patch and then the ABI unstable change separately. But the patch itself is small enough, this is acceptable.

I'll follow-up with additional cleanups for the ABI macros, I've had something in mind for a while.

This revision was not accepted when it landed; it landed in state Needs Revision.Feb 5 2022, 3:02 AM
This revision was automatically updated to reflect the committed changes.