[MeteorsLiu]

Update native-binding CI to LLGo v1.0.7 through the official setup-llgo action so C callback aliases are checked with the compiler fixes included in the release.

The implementation includes:

• Use xgo-dev/setup-llgo@v0.2.0 with LLGo v1.0.7, Go 1.27.0 and LLVM 22.
• Remove the old source checkout, manual compiler build and LLVM Go binding downgrade; use the action's exported PATH and LLGO_ROOT.
• Install LLD 23 for native macOS arm64 links and select its actual Homebrew path through --ld-path, while keeping LLVM 22 as the compiler toolchain.
• Preserve the existing test matrix and package checks. Local Linux amd64 validation with the checksum-verified v1.0.7 release passes the CI test command and all 840 root-package tests from feat(c): add libc bindings with native ABI coverage #45, including X__ComparFnT/size; the GitHub Actions run also passes all four jobs: Ubuntu and macOS LLGo tests, the Go build and the Windows LLVM demangle bridge.

Closes #54.

This keeps the CI toolchain update separate from the libc binding PRs and addresses the old compiler's incorrect C callback alias size calculation.

[fennoai]

Review summary

Clean, well-scoped CI change. Replacing the ~30-line manual LLGo source checkout + build with the official xgo-dev/setup-llgo@v0.2.0 action is a clear maintainability and CI-time win, and the removal of LLGO_ROOT plus the $RUNNER_TEMP/llgo invocations is complete — no dangling references to the old .llgo path remain. Two small points on the new macOS linker step and the action pin are worth a look; both are minor and non-blocking (see inline comments).

Optional, pre-existing (not introduced by this PR)

• LLGO_BUILD_CACHE: 'off' (lines 52-56 and 61-66): now that the from-source LLGo build is gone, llgo test compilation is the dominant cost of this job, and disabling the build cache forces a full recompile on every run across both matrix OSes. If a cold cache is not strictly required for correctness, consider enabling it; if it is intentional (avoiding stale-artifact flakiness), a one-line comment documenting the tradeoff would help future readers.
• Comment at lines 58-60: the "exposes libc++'s C++ ABI … Linux LLVM packages use libstdc++" rationale for the macOS-only cpp/llvm demangle test is questionable — the demangle functions actually exercised take/return C strings and do not cross a C++ ABI boundary, and the Unix link config (!windows) is shared by Linux and macOS. Since this PR removed the sibling explanatory comments, it may be worth correcting or trimming this surviving one.

[fennoai]

Supply-chain: setup-llgo is pinned to a mutable tag, not a commit SHA.

xgo-dev/setup-llgo@v0.2.0 runs in CI with access to the workflow token; a tag can be force-moved upstream to point at different code. This is a mild regression from the step it replaces, which pinned the LLGo checkout to a full commit SHA (ref: 6fc2ef1…). Consider pinning to the commit SHA with a version comment:

uses: xgo-dev/setup-llgo@<commit-sha> # v0.2.0

The toolchain inputs (llgo-version, go-version, llvm-version) stay pinned and the action SHA-256-verifies its own downloads, so residual risk is limited to the action wrapper. Non-blocking.

[fennoai]

The lld@23 linker choice here is undocumented, and the version is hardcoded.

setup-llgo@v0.2.0 already installs, force-links, PATH-exposes, and version-verifies lld@<llvm-version> (i.e. lld@22). This step deliberately installs a different major — lld@23 — with --skip-link and points LDFLAGS --ld-path at its ld64.lld, so it is an intentional override of the action's lld@22, not a duplicate. Two suggestions:

• Add a short comment explaining why lld@23 specifically is needed on macOS arm64 over the lld@22 the action provides. The surrounding workflow otherwise documents its non-obvious decisions.
• lld@23 is hardcoded and decoupled from llvm-version: '22'; if LLVM is bumped later, this will not move with it. A co-located note that the two are intentionally independent would help.

Minor: if brew install partially fails, $(brew --prefix lld@23) could resolve without bin/ld64.lld present, and LDFLAGS would silently point at a missing linker, failing later with a less obvious error. A test -x guard on the resolved path would fail fast.