[clang] [Clang] Allow the use of [[gnu::visibility]] with #pragma clang attribute (PR #145653)

[Saleem Abdulrasool via cfe-commits]

compnerd wrote:

> > It is possible to apply the hidden visibility to member functions on classes. However, it does tend to complicate your ability to reason about the code IMO (although the same argument holds for `__declspec(dllexport)` on member functions. The attribute simply would prevent the member function from participating in dynamic linking - so any other module would need to define their own copy.
> 
> That DOES sound error prone. I wonder if there is use to have this diagnose via a warning that explains this, particularly now that we are allowing this to be more easily added to members.

The interesting thing is the inverse case - which is what we are working towards with the efforts to build LLVM as a DLL. We annotate the members explicitly for their participation in the ABI via `LLVM_ABI`. The intention is that all members will have `__attribute__((__visibility__("hidden")))` by default via `-fvisibility-default=hidden` and then explicit members participate in dynamic linkage by means of the `LLVM_ABI` attribute which expands to `__attribute__((__visibility__("default")))` on ELFish (and MachO) targets.

On Linux, there is the possibility of further optimization by means of having `LLVM_ABI` expand to `__attribute__((__visibility__("protected")))` which permits the symbol to participate in global dynamic linkage, but prevents interpositioning, allowing more efficient code generation (and avoids the need for the use of the GOT within the defining module).

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