Work on this patch was prompted by the CI breakage on GCC caused by https://reviews.llvm.org/D62868. Because the build bots using GCC are on Linux, and this patch removes -fvisibility=hidden when building on Linux, it will silence the CI failures as a side effect.

However, in the future, we can add a similar list using linker version files for Linux, which should work with both GCC and Clang (because it's linker specific anyway).

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

In D66970#1657660, @mclow.lists wrote:

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

This list only contains symbols that we want to export from the dylib, not all symbols. And we already need to update the ABI list (so it passes the check-cxx-abilist test) whenever we add a new symbol to the dylib. So I think this isn't going to be a huge time sink on top of what we already do, but I could be wrong. On the other hand, it has the benefit that we will be able to remove all visibility annotations from the libc++ sources.

In D66970#1657660, @mclow.lists wrote:

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

We can probably automate the creation of this list. Maybe we could add it to CI?

In D66970#1657905, @zoecarver wrote:

In D66970#1657660, @mclow.lists wrote:

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

We can probably automate the creation of this list. Maybe we could add it to CI?

I don't think we want to automate it. The very purpose is to have _explicit_ control over symbols that we export. That way, we do not end up exporting symbols that we wish we did not export.

When a vendor exports a symbols from the dylib, it needs to export it for ever.

I think that controlling via annotations is actually very useful. It will actually still be needed to ensure that libc++ continues to build on Windows properly (which really does want the annotations). The annotations being applied there makes it easy to then handle properly on the other platforms as well. Additionally, diffs explicitly call out the interface in the change, which again helps review the changes. Finally, there are some symbols which are synthesized by the compiler and the visibility for those are controlled by means of the annotation on the associated class. This again is far easier to manage with the explicit annotation rather than the explicit export list.