[libcxx-commits] [libcxx] [libc++] Introduce ABI sensitive areas to avoid requiring _LIBCPP_HIDE_FROM_ABI everywhere (PR #131156)

[Aaron Ballman via libcxx-commits]

AaronBallman wrote:

> > > Do you have breakage with hash specifically as well, or are there other cases?
> > 
> > 
> > The first issue encountered was actually on `std::equal_to`. I've not attempted a rebuild of the entire codebase, however I fully expect to also run into the same issue for at least `hash`, `tuple_size`, and `tuple_element`. I suspect there's also others, besides.
> > > That is quite interesting. I don't really know what the code does, but given the results it seems somehow wrong.
> > 
> > 
> > I don't think it's _wrong_. Rather, I'd say: when the attribute is used the way libc++ has attempted, this intended-behavior of the compiler results in invalid outcomes.
> 
> Whether or not it's used as intended in libc++ doesn't matter. It's inconsistent with itself, which makes it wrong no matter what the intended behvaiour is.

It's an extension, "wrong" is what we say it is. :-)

FWIW, how we got there:
https://github.com/llvm/llvm-project/commit/3a52c44865a7276647a0b05d46e991e3c3a4517d
https://github.com/llvm/llvm-project/commit/79cbd1163afed91085f862442448e092fe79658c

> > It's conceivable that with further investigation we could determine that the behavior of the compiler should be changed -- but I think it's much more likely we'd determine that there's good reason to keep the current behavior of the compiler, and that libc++ should just not attempt use the attribute in this manner.

+1; I still think we should revert. Changing the compiler implementation is risky due to potential for silent breaking changes, so it's not something we should do quickly. And there are people impacted by the changes that are currently in tree, with reproducing code examples at hand. I think this pretty clearly meets our [revert criteria](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy).

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