Does setting the CLANG_PATH environment variable to clang-cl fix this issue?

I've just tested that, and that doesn't do anything. Neither bindgen, nor libclang have any handling for such an environment variable as far I have seen.

bindgen uses libclang-sys, which documents CLANG_PATH here: https://github.com/KyleMayes/clang-sys?tab=readme-ov-file#environment-variables

The usage area is here in bindgen, which calls this function in clang-sys.

But I guess this maybe only affects the clang executable which is used to detect the include paths, and perhaps does not affect the parsing of arguments, which might be done directly via libclang.

Looking at the libclang source, it directly adds clang to the args.
https://github.com/llvm/llvm-project/blob/release/18.x/clang/tools/libclang/CIndex.cpp#L4097

There's also no codepath to switch it to clang-cl reasonably.

Stack is along the lines of:
bindgen::ir::context::BindgenContext::new -> bindgen::clang::TranslationUnit::parse -> clang_sys::clang_parseTranslationUnit (C++) -> clang_sys::clang_parseTranslationUnit2 (C++, adds the clang) -> clang_sys::clang_parseTranslationUnit2FullArgv (C++) -> clang_sys::clang_parseTranslationUnit_Impl (C++)

It would be possible to use clang_parseTranslationUnit2FullArgv directly, but I can't really think of an API that makes sense for that.

https://llvm.org/devmtg/2014-04/PDFs/Talks/clang-cl.pdf mentions clang-cl.exe == clang.exe --driver-mode=cl

Does adding --driver-mode=cl as a clang argument to the builder help?

That seems to half-work at least. It at least needs /clang:-fuse-ld=lld, /link /SUBSYSTEM:WINDOWS, /TP (instead of -x c++), /FI (instead of -include). Haven't tested it in a full build, currently at this:

lld-link: error: undefined symbol: WinMain
>>> referenced by D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:102
>>>               libcmt.lib(exe_winmain.obj):(int __cdecl invoke_main(void))
>>> referenced by D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
>>>               libcmt.lib(exe_winmain.obj):(int __cdecl __scrt_common_main_seh(void))
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Command:

clang "./src/jsapi.hpp" "-I" "<omitted>/dist/include" "-I" "<omitted>/js/src" "/TP" -fms-compatibility --driver-mode=cl /clang:-flto=thin /clang:-fuse-ld=lld "-DRUST_BINDGEN" "-DSTATIC_JS_API" "-std:c++17" "-DWIN32" "-D_CRT_USE_BUILTIN_OFFSETOF" "/FI" "<omitted>/js/src/js-confdefs.h" /link /SUBSYSTEM:WINDOWS 

The /link causes problems though as it's a catch-all, so no inputs are detected, causing stacker for example to fail to build.

Command "clang-cl" "-nologo" "-MD" "-O2" "-Brepro" "-m64" "--driver-mode=cl" "/clang:-flto=thin" "/clang:-fuse-ld=lld" "/link" "/SUBSYSTEM:WINDOWS" "-I" "src/arch" "-DWINDOWS" "-FoC:\\Users\\Redfire\\spiderfire\\target\\x86_64-pc-windows-msvc\\release\\build\\stacker-a0dccd7a5f938667\\out\\src/arch/windows.o" "-c" "--" "src/arch/windows.c" with args "clang-cl" did not execute successfully

Given that BINDGEN_EXTRA_CLANG_ARGS exists, it might be best to just stop adding CFLAGS and CXXFLAGS to bindgen.

I was looking at this again, is there any real difference between CPPFLAGS and CXXFLAGS? I've been using /clang:-flto on CPPFLAGS but not CXXFLAGS to fix my issue with the compilation.

Closing this was an accident...

CPPFLAGS are flags for the C preprocessor. -flto shouldn't affect the preprocessor in any way.

With even more testing, I have isolated the issue to adding -x c++ to the clang args of bindgen.
It should still be fine since the input files are .cpp anyways.

I found that libclang was messing up here, which results in a CXError__ASTReadError.
https://github.com/llvm/llvm-project/blob/87782b216fd3e7a8f8b2de04d4af467b390e9a34/clang/lib/Frontend/ASTUnit.cpp#L1795-L1802

I've done some local testing with my mozjs fork on spiderfire with the change (ie removing -x c++ on bindgen) and MOZ_LTO=full,cross CFLAGS=/clang:-flto CXXFLAGS=/clang:-flto RUSTFLAGS=-Clinker-plugin-lto and it builds successfully!

I have confirmed that objects files in js_static.lib, jsapi.lib and jsglue.lib are llvm bitcode (llvm-readobj warns they are llvm bitcode), which means it seems successful.