Potentially add libclang as a build dependency

[LeszekSwirski]

We (V8) are considering changing so of our codegen (in particular, instance type allocation) from being generated by Torque based on torque object definitions, into being generated by a libclang-based helper program that parses C++ object definitions -- the goal is to eventually remove the Torque object definitions entirely and have a single source of truth in C++. We likely don't need a bleeding-edge libclang since we're not going crazy with syntax here and libclang is relatively stable.

We're looking to make this part of the build rather than checking it in (like static roots) because the ifdef explosion is likely to be more severe. We want to make sure that downstream embedders are not entirely broken by this approach, and have some solution that's compatible with our plans. Please let me know if there are any insurmountable obstacles for you with an approach like this.

[joyeecheung]

Some ideas discussed offline:

1. Looks like clang/llvm is generately required in build support at this point. One outlier is GCC though it's mostly only supported on Linux now. In the case of using libclang as a parser it shouldn't be too different from adding a build dependency of other kind.
   • For system-vendored stable installations, on Linux this is usually available in a separate package (e.g. clang-devel/libclang-dev) but seems available everywhere clang/llvm is available. On Windows I found it under C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\Llvm\lib\libclang.lib (VS 2026) , on Xcode installations on macOS, I found it in /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libclang.dylib
   • Currently the minimum supported version is 19, upgrade to 20 tracked in Upgrade to Clang 20 and Rust 1.88  #4265. It would be helpful if V8 can stick to stable APIs in libclang that is available in the minimum supported version.
2. One solution for platforms where libclang is less available may be, as long as the files generated are somewhat stable across platforms in the same build configuration, Node.js can pre-generate them using the default build configurations that Node.js supports, and check them into source during V8 updates. At build time instead of pointing at files under out, just point at those checked files, so most platforms don't need to generate them on the fly. That only leaves out those who may need other build configurations to install libclang and point to files under out. Not sure if this makes things simpler or actually more complex, though.