Build win-arm64 libClangSharp with clang-cl to match the LLVM release ABI#807
Open
tannergooding wants to merge 3 commits into
Open
Conversation
These tests exercise native libClangSharp shims that are broken in the win-arm64 22.1.8.2 prebuilt, causing Debug.Fail / NRE when the native lib returns CX_TNK_Invalid for template names. The existing DeclTest guard already covers other shim-dependent tests; extend the same pattern to TypeTest and the baseline generator tests. See dotnet#806. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
… ABI The official LLVM release binaries are clang-built. On Arm64, clang and MSVC disagree on the record layout of over-aligned non-POD base classes such as clang::TemplateSpecializationType (clang rounds the over-aligned base up to a full slot; MSVC-Arm64 packs the next base into its tail padding), so an MSVC-built shim reads members of clang-built types at the wrong offset and returns garbage (e.g. getTemplateName yielding CX_TNK_Invalid). win-x64 layouts agree between the two compilers, so only win-arm64 is affected. Build the win-arm64 shim with the release's own clang-cl (via Ninja) so its layouts match the libs it links against. Generalize the diaguids.lib repoint in libClangSharp/CMakeLists.txt to also apply under Ninja + clang-cl, sourcing the Visual Studio root and target arch from VSINSTALLDIR and the compiler arch id when the VS-generator variables are absent. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…m64 rebuild The win-arm64 shim is now compiled with clang-cl, so the native package needs a new revision to republish. Bump the five runtime nuspecs, the meta nuspec, and runtime.json from 22.1.8.2 to 22.1.8.3. The managed libClangSharp pin in Directory.Packages.props stays at .2 until .3 is published, matching how prior native republishes were sequenced. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
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
1 participant
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.
What
Builds the
win-arm64libClangSharpshim with the LLVM release's ownclang-cl(via-G Ninja) instead of MSVC, so the shim's C++ record layouts match the clang-built LLVM binaries it links against.Why
The official LLVM release binaries are clang-built. On Arm64, clang and MSVC disagree on the record layout of over-aligned non-POD base classes — e.g.
clang::TemplateSpecializationType(TypeWithKeyword+FoldingSetNode, where theTypebase isalignas(16)):Templateat 40.Templateat 32.So an MSVC-built shim reads members of clang-built types at the wrong offset and returns garbage —
clangsharp_Type_getTemplateNameyieldsCX_TNK_Invalid, which surfaces as thewindows-arm64CI failures onTemplateNameTest/DependentTemplateBaseTest. This is a long-standing MSVC-vs-clang ABI disagreement specific to theaarch64-pc-windows-msvctriple (reproduces across every MSVC Arm64 and clang version tested);win-x64layouts agree, so onlywin-arm64needs the change.Changes
scripts/build.ps1— routewin-arm64libClangSharpthrough Ninja + the release'sclang-cl(imports the VS dev environment viavcvarsall, puts the LLVMbinonPATH).win-x64keeps using MSVC.sources/libClangSharp/CMakeLists.txt— generalize thediaguids.librepoint (which works around the absolute path LLVM bakes intoLLVMExports.cmake) to also apply under Ninja + clang-cl, sourcing the VS root/arch fromVSINSTALLDIRand the compiler arch id when the VS-generator variables are absent.README.md— document thewin-arm64clang-cl special-casing.The interim skip guards for
TemplateNameTest/DependentTemplateBaseTest(issue #806) stay until the native package is regenerated and republished with this fix.Validation
Built the shim locally on an Arm64 box via the real
scripts/build.ps1 -regeneratenativepath (fresh build dir, simulated the LLVM build-machinediaguidspath to confirm the repoint), binplaced the result, and ran both previously-failing tests:TemplateNameTestpasses andDependentTemplateBaseTestis 8 passed / 0 failed (was 8×Debug.Fail).