[libcxx-commits] [PATCH] D103160: [libc++] Update ABI docs

[Louis Dionne via Phabricator via libcxx-commits]

ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

I think this looks really good now, thanks a lot and sorry for the delay!



================
Comment at: libcxx/docs/DesignDocs/ABIVersioning.rst:15
+frozen and new ABI-breaking changes will start being applied to version ``3``;
+but this has not happened yet.
 
----------------
Quuxplusone wrote:
> SeanP wrote:
> > What is the intension when version "2" becomes stable?  Vendors will have compilers in service that support version 1 and the vendor customers will have many applications and shared libraries that use version 1.  What will happen when the vendor wants to step up to version 2?  Will the vendor be able to ship both version 1 & version 2?  Will applications be able to use both versions either via object file dependencies (eg. static libs) or via shared libraries?  Or is there a complete breakage?  I hope that is not the case as that would force 3rd party providers to provide two versions of any shared library they sell.
> I don't know, but I bet "there is a complete breakage" is closest to the truth.
> One thing that's not mentioned in this doc (that probably should be): libc++ nests everything under a C++11 "inline namespace," e.g. `std::any` is really named `std::__1::any`. The `__1` corresponds to C++ macro `_LIBCPP_ABI_NAMESPACE`, which is constructed out of the `_LIBCPP_ABI_VERSION`. So, if you step up to version 2, you'll find that all your standard library stuff has moved to e.g. `std::__2::any`.
> You almost certainly won't be able to ship a shared library that works //equally well with either// `std::__1` or `std::__2`. That's kind of the definition of an ABI break.
> Vice versa, while `_LIBCPP_ABI_NAMESPACE` affects the mangling of `std::any`, it doesn't affect the mangling of `struct Your::M : std::any {}`, which has all the same problems as `std::any`, ABI-wise. https://godbolt.org/z/qj7fWzbrx
> What is the intension when version "2" becomes stable?

I don't foresee a point where we will say version 1 doesn't exist anymore. That would imply forcing an ABI break on all vendors simultaneously, which is both a crazy idea and not up to an open source community to decide, IMO.

What I could see happening is that we'll provide version 1, but also provide a stable version 2 that vendors can individually opt into, if it's possible for them to do so. For example, most vendors have an occasion to perform a complete ABI break when they introduce a new architecture, since no software exists on that architecture at the start. That's an open door for them to pick the newer yet stable ABI v2 (once it is stable).

If we do come to a point (a long time from now) where we are OK with dropping support for v1 completely (e.g. because nobody ships it anymore), then we could remove it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103160/new/

https://reviews.llvm.org/D103160