A proposal for ABI migrations in libc++

Hi,

These thoughts are motivated by my rejected std::deque patch.

In general I don't think we have a good mechanism for making
ABI-breaking changes in libc++. The existing mechanism is to
increment _LIBCPP_ABI_VERSION and make all ABI-breaking changes in
the same commit along with the increment. This makes it difficult for
ABI-breaking changes to be developed incrementally, as there is no good
place to keep the changes until the ABI-breaking megapatch; complicates
debugging, as it would be difficult to bisect an ABI-breaking megapatch;
and fails to accommodate implementors who are not constrained by ABI
compatibility requirements.

The proposal I have in mind is to introduce a macro, _LIBCPP_ABI_NEXT,
which all ABI-breaking changes are made conditional on. Defining this
macro will cause _LIBCPP_ABI_VERSION to be defined to some arbitrary
non-numeric value, such as "next" (without quotes). The lib/buildit
and test/testit scripts are modified so that the library can be built
and tested with or without _LIBCPP_ABI_NEXT defined. Any implementor
who does not have ABI compatibility requirements for libc++ may compile
the library with _LIBCPP_ABI_NEXT defined, but the implementor must
ensure that the compiler defines this macro in every C++ translation
unit.

When we are ready to make an ABI transition, the value of
_LIBCPP_ABI_VERSION is incremented and every place in the source code
which is conditional on the definition of _LIBCPP_ABI_NEXT is updated
as if the macro were defined.

Thoughts?

Thanks,

Brief thoughts… I think it would be desirable to be able to have more than one stable ABI along side the"next" ABI. For example, FreeBSD and Mac might want to different stable ABIs.

Also, I’d like a more friendly interface for users of the unstable ABI than an internal libc++ macro… Maybe a clang switch could house it?

Brief thoughts... I think it would be desirable to be able to have more
than one stable ABI along side the"next" ABI. For example, FreeBSD and Mac
might want to different stable ABIs.

I think that should a particular platform need anything more granular
than _LIBCPP_ABI_NEXT, we could do something like put a specific ABI
change behind its own macro and make sure that that macro is defined
on the platforms that need it or if _LIBCPP_ABI_NEXT is defined.
(Or whatever is appropriate for the specific change.) But I think
that can be done incrementally after _LIBCPP_ABI_NEXT is introduced
and on an as-needed basis.

Also, I'd like a more friendly interface for users of the unstable ABI than
an internal libc++ macro... Maybe a clang switch could house it?

+1. Such a flag could also cause the unstable-ABI version of the
library to be linked to.

Thanks,