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

[Martin Storsjö via libcxx-commits]

mstorsjo wrote:

Ok, now I've had a look at this.

This PR produces the following diff in the list of exported symbols from the libc++ DLL:
```
@@ -1,9 +1,3 @@
-  Name: _Z10asprintf_lPPc8locale_tPKcz
-  Name: _Z10snprintf_lPcy8locale_tPKcz
-  Name: _Z10strftime_lPcyPKcPK2tm8locale_t
-  Name: _Z11vasprintf_lPPc8locale_tPKcS_
-  Name: _Z8strtof_lPKcPPc8locale_t
-  Name: _Z9strtold_lPKcPPc8locale_t
   Name: _ZN10__cxxabiv116__enum_type_infoD0Ev
   Name: _ZN10__cxxabiv116__enum_type_infoD1Ev
   Name: _ZN10__cxxabiv116__enum_type_infoD2Ev
@@ -1831,6 +1825,22 @@
   Name: _ZNSt3__17promiseIvEC2Ev
   Name: _ZNSt3__17promiseIvED1Ev
   Name: _ZNSt3__17promiseIvED2Ev
+  Name: _ZNSt3__18__locale10__asprintfEPPcNS0_10__locale_tEPKcz
+  Name: _ZNSt3__18__locale10__snprintfEPcyNS0_10__locale_tEPKcz
+  Name: _ZNSt3__18__locale10__strftimeEPcyPKcPK2tmNS0_10__locale_tE
+  Name: _ZNSt3__18__locale11__mbsrtowcsEPwPPKcyPiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale11__newlocaleEiPKcNS0_10__locale_tE
+  Name: _ZNSt3__18__locale12__localeconvERNS0_10__locale_tE
+  Name: _ZNSt3__18__locale12__mb_len_maxENS0_10__locale_tE
+  Name: _ZNSt3__18__locale12__mbsnrtowcsEPwPPKcyyPiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale12__wcsnrtombsEPcPPKwyyPiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale7__btowcEiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale7__wctobEtNS0_10__locale_tE
+  Name: _ZNSt3__18__locale8__mbrlenEPKcyPiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale8__strtofEPKcPPcNS0_10__locale_tE
+  Name: _ZNSt3__18__locale9__mbrtowcEPwPKcyPiNS0_10__locale_tE
+  Name: _ZNSt3__18__locale9__strtoldEPKcPPcNS0_10__locale_tE
+  Name: _ZNSt3__18__locale9__wcrtombEPcwPiNS0_10__locale_tE
   Name: _ZNSt3__18__rs_getEv
   Name: _ZNSt3__18__sp_mut4lockEv
   Name: _ZNSt3__18__sp_mut6unlockEv
```

So a handful of `locale_t` specific functions are removed and others appear.

A regular build of LLVM/Clang on top of this libc++ doesn't seem to reference any of those symbols, so we're not breaking the base toolchain if doing this change. That's good. :-)

I had a look in an install of msys2/clang64 to see how many packages/executables would be affected. I don't have a whole lot of packages installed so it's not a very thorough investigation, but if @lazka or @mati865 happen to have more packages installed locally maybe they can try too.

In `/clang64/bin` I ran `ls *.exe *.dll | wc -l` and noted that I happen to have 540 executables/DLLs lying around. Out of those, 287 seem to actually be referencing libc++.dll: `grep libc++.dll *.exe *.dll | wc -l`

How many of them would be bothered by this change?

```
for i in $(grep libc++.dll *.exe *.dll | grep "Binary file" | awk '{print $3}'); do if llvm-readobj --coff-imports $i | grep -q locale_t; then echo $i; fi; done
```
In my case, I only get one single hit, `libboost_locale-mt.dll`.

So if this is the scale of the breakage, perhaps it's not worth the effort to keep providing the old symbols for backwards compatibility. But let's wait for more numbers from the msys2 maintainers before concluding this.

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