[libcxx-commits] [libcxx] [libc++] Refactor the Windows and MinGW implementation of the locale base API (PR #115752)

[Martin Storsjö via libcxx-commits]

mstorsjo wrote:

> Since this changes the name of some types and entry points in the built library, this is effectively an ABI break on Windows (which is acceptable since we don't promise ABI stability on that platform).

I'd like to clarify/reiterate some nuances about ABI stability on Windows. While I can't claim that the libcxx project promises ABI stability there, there are two quite different cases:

In MSVC environments, we've flagged this a number of times before, making it clear that we do break the ABI occasionally, and this is accepted.

In MinGW environments (using the Itanium C++ ABI), there are a number of setups that do use older libc++ DLLs with newer builds, where ABI compatibility generally is desired - both around llvm-mingw, and within msys2. So far, we've had a number of minor ABI breaks, where such a break (if they happen to break a small minority of packages) has been accepted and tolerated. But I would request that this isn't treated as blanket permission to break the whole ABI just because there's no formal guarantees either; breaking the ABI in this environment _can_ cause grief to our users - proportional to the number of changed symbols and how frequently they are used of course.

CC @lazka @mati865

---

That said, I'm not sure how often these particular symbols really are referenced in practice; are they implicitly embedded in many cases, or are they only referenced if the user code explicitly uses locale things? In the latter case this is probably fine, in the former case, it will probably cause a lot of problems for msys2.

---

Separately; I see that this touches a MinGW configuration that we don't have CI coverage for - using MinGW with msvcrt.dll instead of UCRT. This configuration doesn't pass all tests (as msvcrt.dll is quite lacking in many ways), but I ship builds with this configuration in each release.

I can easily add CI coverage for this build configuration; 128 tests are failing in it, so it'll take a little while to get the tests running there, but we can easily add plain build testing of it at least.

https://github.com/llvm/llvm-project/pull/115752