Expose LLVM artifacts and fix warnings#1
Merged
Conversation
These are not used by the toolchain itself but are often useful to third-party tools and IDEs as complementary developer tools.
libclang is Clang's C API as a shared library. Exposing it here lets downstream rules (most commonly Rust bindgen for generating FFI bindings against C/C++ headers) consume the already-extracted DLL and import library without a separate LLVM download.
Fixes the "imported but reported as indirect dependencies" warning for consumers that `use_repo` an `llvm_<version>_<host>` repo.
mxpv
changed the title
Follow-up to e5b8d11 which added these paths to .gitignore.
The flag only affects CodeView output (enabled via -gcodeview). When kept in base_compile_flags, clang warns "argument unused during compilation" on every non-debug compile. Move it alongside -gcodeview so both flags travel together.
Clang ships intrinsic headers (xmmintrin.h, etc.) at
lib/clang/<version>/include/. Without that path on the include search,
Clang falls through to MSVC's headers from the Windows SDK sysroot,
which declare SSE intrinsics as `extern` rather than inline — leaving
them as unresolved symbols at link time.
Wire lib/clang/<version>/include/ into the `include_paths` cc_args for
both `clang` and `clang-cl` frontends, so Clang's own headers are
found first.
Resolve the {LLVM_VERSION} placeholder via ctx.template substitution
in private/llvm_repo.bzl so the path materializes to a concrete version.
Owner
|
It is good improvement. I am expected a lot of corner cases like this, and I am glad people are contributing to fixing them. I have enabled auto-merge. If the test pass, it will be merged. Thank you |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thanks for this project!
I'm building a project that mixes C++ and Rust (with Rust bindgen for FFI bindings). It builds on macOS via
toolchains_llvm, but I hit a few gaps while trying to bridge the Windows build up viatoolchains_msvc:clang-formatandclang-tidyare shipped in the LLVM tarball but aren't exposed as Bazel targets — aspects often run them against C++ sources.libclang(DLL + import library) isn't exposed either, so Rust bindgen — which links against the Clang C API — can't locate it.use_repo(...)get Bazel'simported but reported as indirect dependencieswarning.-gno-codeview-command-linesits in the clang frontend'sbase_compile_flagsbut only has an effect alongside-gcodeview. Clang emits "argument unused during compilation" on every non debug compile. Moved alongside-gcodeviewso both flags travel togetherlib/clang/<version>/include/) aren't on the include search path, so SSE intrinsics (_mm_rsqrt_ssetc.) resolve to MSVC's extern declarations from the Windows SDK and fail to link. Wired the path intoinclude_pathsfor bothclangandclang-cl(msvc-clis unaffected — native MSVC handles its own headers.)