Libcxx non-character-T deprecation breaks Apache Arrow

@ldionne picking this up from Deprecating std::string<T> for non-character T

Just FYI - we (Google) hit some breakages due to the char_traits change and usage in Apache Arrow here: Search · basic_string_view · GitHub

I think we’re at least a bit blocked by this - not sure what we’ll do, whether it’s find some way to patch the code internally while getting it fixed upstream, or maybe we have some folks who can fix upstream, etc, but it’s at least a bit of a problem.

⚙ D138596 [libc++] Keep char_traits<T> for arbitrary T around until LLVM 18 should actually fix that problem. It’s my priority, I just have not had time to finish it today since it didn’t pass the CI the first time around and I had to get going. I’ll get to it tomorrow morning.

I will also be writing a post about setting up an official policy for handling these sorts of issues. I want to determine some sort of SLA and set the downstream expectations for handling these events because the current state of things sucks.

On your end, you got broken by one of our change. You know it’s possible to mitigate the breakage but you don’t know whether we’re aware of it, whether we want to do it and how long it’s going to take (until I tell you those informations). Until then, you have downstream breakage and I am certain that throws a wrench into various processes and creates all kind of trouble. Thats sucks.

On our end, we landed a legit change. We were notified that some non-legit code was broken, and we agreed that we could do something to mitigate it. But things are broken for some people, so this simple change essentially turns into a super high priority thing. The frustrating part is that this happens because some « random » (not unimportant) project somewhere decided to live at head instead of using the agreed upon delivery channel for libc++ changes, aka LLVM releases. This puts us in a situation where any change can potentially turn into a high priority issue, which means that we’re always « on call » in some sense. This sucks, too.

Now, libc++ benefits a lot from the fact that this project is living at head, since it finds various issues earlier and we’re able to deliver better releases as a result. So we don’t want to put an end to that relationship, but rather we want to formalize it a bit so that things work more smoothly on both sides.

1 Like

ah, sorry, hadn’t realized it was already being discussed on the review - good stuff, sorry for the duplicate signal