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

Fri Jun 3 10:20:27 PDT 2022

philnik added a comment.

I think it would be a good idea to couple the ABI version to the C++ version. i.e. if `-std=c++20` use ABIv1 by default (and allow people via a compiler flag to use ABIv2) and if `-std=c++2b` use ABIv2 (and have no way to use ABIv1). That would force people to use the new ABI as they update to a newer standard. This would mean that an ABI is never really deprecated. Old C++ version would get deprecated and removed. I think a good number would be 5 C++ releases. That would mean that C++03 should have been deprecated with the release of C++20 and C++11 should be deprecated with the release of C++23. After deprecating the oldest supported version for one C++ release it should be removed (i.e. C++03 will be removed after C++23 has been released and so on).

> Do we start doing all development on ABI v2 by default and keep around one (or several) CI jobs to continue testing ABI v1?

I think it would make sense to use the default ABI version. i.e. Use ABIv1 For C++03 to C++20 and use ABIv2 for C++23.

> Do we start building ABI v2 by default when someone configures libc++? What ABI version do we ship in the LLVM release?

I don't know how complicated it is, but I would guess all currently supported ABI version should be built and shipped.

> 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.

With 4 C++ releases + 1 deprecated makes 15 years time for switching to the new ABI. I think that is enough time.

> 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.

Should that kind of discussion be on Discourse?

> 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.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126462