[libcxx-commits] [PATCH] D126462: [libc++] Re-enable std::pair trivial copy constructor for FreeBSD >= 14

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added a comment.

In D126462#3555878 <https://reviews.llvm.org/D126462#3555878>, @ldionne wrote:

> The change itself LGTM.
>
> Stabilizing ABI v2 raises some interesting questions. For example, if we stabilize ABI v2, does it mean that we consider ABI v1 as "deprecated"? Do we start doing all development on ABI v2 by default and keep around one (or several) CI jobs to continue testing ABI v1? Do we start building ABI v2 by default when someone configures libc++? What ABI version do we ship in the LLVM release?

I think we can ship different dylibs using different ABI versions making the transition easier.

> Concretely, if we deprecate ABI v1, we'll put everyone who require ABI stability in a situation where they are using a deprecated thing. Unless there is a rather serious effort from those folks (I include myself here) to move off of ABI v1, there is basically no timeline for moving off, which means that we'd have introduced a deprecation situation with no real horizon for getting out of it. So far, our ABI flags have been treated as just knobs -- basically you cherry-pick the ABI changes you want when you introduce a new target, and that's what defines your ABI on that target. You then keep the same ABI until that target is end-of-lifed, which may often be not-in-the-foreseeable-future.
>
> So while I do support migrating to a newer ABI in principle, I think the discussion needs to happen a bit more widely in the LLVM community. I think it should be a common library + compiler effort, and we should design some sort of plan for how we're going to push vendors over to the new ABI over a course of X years, and then remove support for the old ABI. Note that X can be a large number of years, but it has to be finite, otherwise we'll just create problems for ourselves by adding one axis in the configuration space that we need to support in libc++.
>
> I'm interested to hear what others think about this.

In general I like to get a stable ABI v2 since some bug-fixes require ABI v2, e.g `_LIBCPP_ABI_REGEX_CONSTANTS_NONZERO`.
Another reason to switch to ABI v2 would be to make some of our optimizations available for a larger audience.
However in my experience such an ABI change is quite disruptive, even on open source platforms. libstdc++5.0 changed
their ABI to avoid COW in `std::string` (which was needed to support C++11). I recall this gave quite some issues when it
happened. In fact I even had the joy to re-experience these issues last year. I expect this to be even worse for platforms
that use more close-source software; thus I expect this to be a larger issue for Apple.

I think it's good to start the discussion whether or not we should stabilize ABI v2, maybe discord is the better place for that discussion


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126462