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

[Nikolas Klauser via libcxx-commits]

philnik777 wrote:

> Defining custom specializations of std classes is common. Building shared libraries without using any symbol visibility attributes, and expecting the default behaviors is also common. Neither are a weird edge case.

You say that, but there has been a single report of someone affected by this so far. That makes the claim that this is common somewhat questionable.


> > FWIW we can work around the problem for specific classes in the library, which would be annoying, but definitely better than reverting.
> 
> I don't think this can be worked around for only specific classes, because (somewhat sadly, IMHO) the standard permits user specializations of nearly everything in the stdlib (other than a small list of explicit prohibitions).

TBH I really don't care about this use-case. Users almost never define their own specializations of specific classes except for ones that are specifically designed for it. I'm quite certain that every implementation would break in spectacular ways if you actually tried to specialize quite a few classes. At least for libc++ that's certainly the case.

> > we'll work around the problem in the library until all compilers we support have been fixed.
> 
> While I see there's some inconsistency between compilers on what to do about conflicting attributes, the core issue is that visibility is inherited from the first namespace decl to the second, if the second _doesn't_ have any visibility attribute. Compilers agree upon that, and I don't think it's something that can or should be changed.

It's not though. See https://godbolt.org/z/GEbMnod1x. Note that `hash<S>::func()` has hidden visibility, even though the first namespace has an explicit markup that it should have default visibility.

> That is, the following is the _expected_ behavior from the compiler -- but, the resulting behavior of hiding a user-defined specialization is invalid. I believe this implies libc++ simply must not declare hidden visibility on public namespaces (it may on private implementation details namespaces).
> 
> ```
> // system header
> namespace [[gnu::visibility("hidden")]] FOO {
> ...
> }
> 
> // user code:
> namespace FOO {
>   // function given hidden visibility, because of previous visibility attribute.
>   void f();
> }
> ```
> 
> [edit: changed example to use generic namespace name for clarity]



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