[llvm] [Support] Add clang tooling generated explicit visibility macros (PR #113097)

Saleem Abdulrasool via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 18 11:11:33 PST 2024


================

----------------
compnerd wrote:

> It would generally be nice if the old LLVM_EXTERNAL_VISIBILTY, LLVM_LIBRARY_VISIBILITY and LLVM_ALWAYS_EXPORT and the new macros could be consolidated. Having 3 old macros on top of 5 new ones really doesn't make it easy to understand when you're supposed to use which one.

This has been my concern as well. However, this is currently an intermediatory step. The desired end goal is to have ~3-4 of these macros for the libraries that we want to support.

In my mind the ones that we want:
- `LLVM_SUPPORT_ABI` - ABI surface for LLVMSupport
- `LLVM_ABI` - ABI surface for LLVM (DSO)
- `LLVM_C_ABI` - ABI surface for llvm-c
- `CLANG_ABI` - ABI surface for clang (DSO)
- `LLDB_ABI` - ABI surface for LLDB (DSO)

This would allow most of the common uses of the library builds be possible on all the platforms. There is a need for splitting out LLVMSupport as it is so commonly used, and LLVM and LLVM C are separate as there is somewhat of an ABI guarantee on the LLVM C interface.

> And on that note, it would be great to have a section in https://llvm.org/docs/ProgrammersManual.html that explains the different ABI macros and when you're supposed to use them. As these are going to be become widespread now, having a reference that we can point people to will be helpful. (There is some limited documentation in Compiler.h, but it does lose nuances like the "only use if there is an out of line member" guideline mentioned above.)

I agree that documenting them is important. However, my concern is that it is going to spread fear and confusion due to the current state. We need to get to the state where the macros are properly setup so that we are able to build the DLLs with the reduced macro set to demonstrate that we are in the right state. At that point, as this becomes part of the development workflow, it would be something that must be documented and have clear guidelines on how to use the tooling to verify (as well as builds).

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


More information about the llvm-commits mailing list