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

[Derek Schuff via libcxx-commits]

dschuff wrote:

This change is causing some errors that I'm not 100% understanding; I'm not sure if there is an issue with this PR or if I'm doing something wrong.

I have an application where we define a standard hasher for our type:
my_header.h
```
namespace std {
template<> class hash<wasm::HeapType> {
public:
  size_t operator()(const wasm::HeapType&) const;
};
}
```
with an implementation in my_impl.cc. This file gets linked into an ELF DSO (mylib.so). Then the type is used as an unordered_map key, in an object file, which is linked into the final binary, against mylib.so (i.e. something like `clang obj1.o obj2.o mylib.so -o a.out`). We are linking against our own locally-built DSO of libcxx, hence our CI noticed this.

Before this change mylib.so contained a public symbol for the hash function:
```
0000000000fa2de0 g     F .text	0000000000000009              _ZNKSt3__24hashIN4wasm8HeapTypeEEclERKS2_
```
After the change, the symbol is local and hidden:
```
0000000000f4de70 l     F .text	0000000000000009              .hidden _ZNKSt3__24hashIN4wasm8HeapTypeEEclERKS2_
```

Linking everything statically instead of with mylib.so works fine.
Is it expected that defining a hash function in `namespace std` this way should result in a hidden symbol that is thus not exported from any DSO that it gets linked into? If not, maybe this new way to mark definitions as hidden is leaking somehow into the user code?



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