[libcxx-commits] [libcxx] [libc++] Reduce the dependency of the locale base API on the base system from the headers (PR #117764)

[Louis Dionne via libcxx-commits]

ldionne wrote:

> As I said on the issue, it looks pretty common: [https://grep.app/search?q=_XOPEN_SOURCE%20500&filter[lang][0]=C%2B%2B](https://grep.app/search?q=_XOPEN_SOURCE%20500&filter%5Blang%5D%5B0%5D=C%2B%2B)

Actually, almost all of the hits in a file named `mutex.h` (with the comment `// may be needed to get the rwlock calls`) seem to be coming from a copy of the same sources. So it looks like there's only 3x unique instances of it:
- Abseil
- `mutex.h` copied all over the place
- two meson test cases

> The thing we hit in practice is that `<chrono>` used to work, and now it doesn't. If it's easy to fix that, might as well?

The problem is that I don't know how to fix it "properly". I can certainly silence this specific error, but as seen in the the CI failures, "alternate" (to avoid the world "legacy") definitions of `_XOPEN_SOURCE` seems to break the code in various ways, and that's a pre-existing issue. So it's hard for me to put a test on it and make sure that we don't break this again in the future. Right now, the only alternative I can think of is to explicitly list all of the headers that are currently broken with `_XOPEN_SOURCE=500` for each platform, and to carve out the test to `UNSUPPORT` those. That would prevent any backsliding of our `_XOPEN_SOURCE=500` support (if we can call it that), but I wonder if that makes sense.

I guess we could do that as a stopgap until we refactor things such that we truly don't care about what that macro is defined to in the future, if that ever happens. I think that would require defining some symbols in the dylib (where we control the build flags).

> (I _do_ have the opinion that libc++ generally tends to be not very friendly to update. We're currently 3 weeks behind again, _just_ down from 5 weeks, due to at least 4 things that need some kind of tweak landing in fast succession. And this year, our libc++ autoroller needed significantly more handholding than last year. This isn't really the forum for that, though :) If there's interest, I can do an experience report writeup for this year – but I'm guessing this is all working as intended.)

I'd be curious to know what roadblocks you encountered in your recent rolls. While you're an early adopter and updates can't be 0 work, we've been trying to provide transition paths for most potentially-breaking changes we make (partly as a result of past feedback like yours). I'd like to know in what cases that didn't work for you so we can either say "yeah, that one was intended" or improve in the future.


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