Repository navigation
Move to exactly LLVM 23.1.3 - #127
Conversation
The Windows jobs check the digest of the archive. macOS takes the release of LLVM with its digest instead of Homebrew's formula, which moves to every new version. LLVM 23 hands the object linking layer creator a memory manager, and its compression reaches the backend without LLD, so the backend links zlib and zstd on Windows. Linux follows once the toolchain archives are published.
Linux now takes the libc++ archives of toolchain-llvm-23.1.3-libcxx-1: the version, revision and digests in the Go helper and the digests in both Containerfiles agree, which the helper's test enforces. The LLVM repository rule compares llvm-config --version with 23.1.3 and stops the build otherwise, so no platform can drift to another release unnoticed. Windows was built with the check in place; the other platforms are covered by this branch's CI. The Linux C++ compiler stays the distribution's clang, which builds against LLVM's libraries and headers. Co-Authored-By: Claude Opus 5.5 <[email protected]>
![inspect-review[bot]](https://avatars.githubusercontent.com/in/3177512?s=60&v=4){kind=small}
There was a problem hiding this comment.
inspect review
Triage: 36 entities analyzed | 0 critical, 0 high, 32 medium, 4 low
Verdict: standard_review
Findings (0)
Reviewed by inspect | Entity-level triage found 0 high-risk changes
PR Summary by QodoPin the compiler to LLVM 23.1.3 on every platform
AI Description
Diagram
High-Level Assessment
Files changed (17)
|
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
The release of LLVM for macOS has no RTTI, unlike Homebrew's, so JitSession.cpp did not link: ErrorInfo<ErrorList> needs the type information of ErrorInfoBase. The backend now compiles without RTTI on macOS. The macOS job ran out of its 75 minutes because a new LLVM leaves the build cache empty. It gets the time for a cold build of each step. prebuild took any llvm-config as ready, and the build then refused it. On Windows and macOS it now reports a wrong version and where to get the right one; a test keeps its version equal to the one llvm.bzl requires. Co-Authored-By: Claude Opus 5.5 <[email protected]>
There was a problem hiding this comment.
inspect review
Triage: 42 entities analyzed | 0 critical, 0 high, 36 medium, 6 low
Verdict: standard_review
Findings (0)
Reviewed by inspect | Entity-level triage found 0 high-risk changes
|
Self-review: every platform now builds against exactly LLVM 23.1.3 and llvm.bzl refuses any other. macOS needed -fno-rtti for the backend, since LLVM's macOS release has no RTTI, and a longer job limit for the one cold build after the cache key changed; that cold run passed. Qodo's bootstrap finding is handled: prebuild check reports a wrong LLVM version on Windows and macOS with the release to get, and a test keeps prebuild and llvm.bzl on the same version; the guide points readers at that check, so it stays. inspect-review found nothing. 40 checks green on a9cf2db. |
Moves the compiler to exactly LLVM 23.1.3 on every platform.
toolchain-llvm-23.1.3-libcxx-1, with digests recorded in the Go helper and both Containerfiles.llvm-config --versionis not 23.1.3.JitSession.cppfollows the changed ORC creator signature; on Windows the backend links zlib and zstd.Verified locally on Windows:
develop buildwith the version check, the bundle, and the native suites;go test ./internal/development. The Linux C++ compiler stays the distribution's clang. macOS now uses the release archive rather than Homebrew's LLVM, so its zstd lookup is proven only by this PR's CI.