Windows build failure with -DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS: too many symbols exported

[akbyrd]

Back for round 3 (#60109 #56109)

The included PrintFunctionNames example can't be built because clang exports 82789 symbols, which exceeds the linkers limit.
clang.symbols.zip

error message

LINK : fatal error LNK1189: library limit of 65535 objects exceeded

cmake invocation

set COMPILER="C:/Program Files/Microsoft Visual Studio/2022/Professional/VC/Tools/MSVC/14.40.33521/bin/Hostx64/x64/cl.exe"

cmake -A x64 -Thost=x64 ^
	-DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" ^
	-DLLVM_EXPORT_SYMBOLS_FOR_PLUGINS=1 ^
	-DCLANG_PLUGIN_SUPPORT=1 ^
	-DCLANG_BUILD_EXAMPLES=1 ^
	-DLLVM_ENABLE_IDE=1 ^
	-DLLVM_INCLUDE_BENCHMARKS=0 ^
	-DLLVM_INCLUDE_EXAMPLES=0 ^
	-DLLVM_INCLUDE_TESTS=0 ^
	-DLLVM_TARGETS_TO_BUILD=X86 ^
	-DCMAKE_ASM_COMPILER=%COMPILER% ^
	-DCMAKE_C_COMPILER=%COMPILER% ^
	-DCMAKE_CPP_COMPILER=%COMPILER% ^
	-Wno-deprecated ^
	..\llvm

Clang version 18.1.3
VS version 17.10.0

[akbyrd]

For a data point, removing all private class methods drops the symbol count to around 42k.

# Skip private class methods
elif re.search("@[A-F].*@Z$", symbol):
    return None

This is unlikely to be shippable, since I assume a function from clang that calls a private class method could be inlined into a plugin module. At that point it would presumably need to link against the symbol.

But it's still interesting from the perspective of just how much is being exported that in theory shouldn't be. I imagine the ideal solution here is to explicitly declare which functions are expected to be exported. Something akin to the typical FOO_API macro business that resolves to __declspec(dllexport) or __declspec(dllimport) on Windows. Or maybe only exporting symbols from specific files.