Upgrade LLVM toolchain from 21.1.8 to 22.1.8#296
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
I didn't find any issues — the 21→22 substitutions are complete and consistent across all Dockerfiles, workflows, and build scripts. Deferring to a human only because a compiler major-version bump affects every produced artifact; worth a maintainer confirming the full preview-build matrix is green before merge.
Checked: no stray 21 / 21.1.8 references remain in build infra (Dockerfiles, workflows, *.sh/*.ps1/*.ts); windows-release.ps1 has no hardcoded version. The Dockerfile hardcoded ./llvm.sh 22 matches the updated LLVM_VERSION ARG. Alpine 3.24 bump is required for the clang22/llvm22 apk packages. compiler-rt tag + SHA256 pairs updated in lockstep for both darwin and windows.
Extended reasoning...
Overview
Mechanical LLVM toolchain bump 21.1.8 → 22.1.8 across 6 Dockerfiles, 3 GitHub workflow files, build.ts, and mac-release.bash. Changes are pure string substitution: LLVM_VERSION ARGs, apk package names (clang21→clang22 etc.), the Alpine base image (3.23→3.24, required for clang22 packages), compiler-rt release tags + their SHA256 pins, workflow env/input defaults (including a stale 19→22 cleanup), and clang-21/clang++-21 binary names in local build scripts. Follows the exact pattern of the prior #153 (19→21) bump.
Security risks
None introduced by the diff. All new remote assets (compiler-rt-darwin/windows-22.1.8, LLVM-22.1.8-woa64.exe) are fetched from the same origins as before (oven-sh/WebKit releases, llvm/llvm-project releases) and the mirrored compiler-rt assets remain SHA256-pinned via Docker ADD --checksum. No new external endpoints, no permission changes to workflows.
Level of scrutiny
The diff itself needs low scrutiny — it's a find/replace with no logic changes, and I grepped for stragglers (none in build infra; only a historical note in jsc.md). However, the effect — changing the compiler that builds the entire JSC engine for every platform — is high-impact. New clang majors can introduce warnings-as-errors, codegen changes, or LTO/sanitizer behavior differences that only surface at build or runtime. That validation is CI's job, not code review's, but a human should be the one to look at the preview-build matrix results and pull the trigger.
Other factors
The PR description is thorough: the author pre-published the compiler-rt-{darwin,windows}-22.1.8 release tags, verified LLVM-22.1.8-woa64.exe exists upstream, and explicitly noted the intentionally-stale LLVM 21's CodeView emitter comment on the disabled arm64-lto variant. If any SHA256 pin is wrong the Docker build fails loudly. No outstanding review comments. Given all that, this is very close to auto-approvable — I'm deferring only because toolchain bumps for a production runtime are the kind of change a maintainer should consciously sign off on after seeing green CI.
WalkthroughThe change updates LLVM toolchain selection from LLVM 21 or 19 to LLVM 22 across CI workflows, Dockerfiles, compiler-rt artifacts, build autodetection, and macOS release defaults. ChangesLLVM 22 migration
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
Comment |
There was a problem hiding this comment.
LGTM — mechanical LLVM 21→22 version bump following the same pattern as #153.
What was reviewed:
- Grepped for stray
21/21.1.8/clang-21references across Dockerfiles, workflows, and build scripts — none remain. Dockerfile.macos/Dockerfile.windows: tag, URL filename, and sha256 pins all updated together;ADD --checksumfails the build if any are wrong.Dockerfile.musl: alpine base, apk package names,CC/CXX, andllvm22include/bin paths all bumped consistently.windows-release.ps1uses the unversionedC:/LLVMpath fed by the updated$llvmVersioninbuild-reusable.yml, so no change needed there.
Extended reasoning...
Overview
This PR bumps the LLVM toolchain from 21.1.8 to 22.1.8 across all build infrastructure: six Dockerfile* variants, three GitHub Actions workflows, and two local build scripts (build.ts, mac-release.bash). Every change is a version-string substitution (21→22, 21.1.8→22.1.8) plus the corresponding sha256 re-pins for the mirrored compiler-rt-{darwin,windows}-22.1.8 release assets and an alpine:3.23→3.24 base bump to pick up the clang22/llvm22 apk packages. The fail-fast: false matrix additions in the diff are already on main via dbb327e. No source code is touched.
Security risks
None. The only external inputs are the new compiler-rt release assets and the upstream LLVM-22.1.8-woa64.exe, all fetched from oven-sh/WebKit releases or llvm/llvm-project releases. The Docker ADD --checksum=sha256: directives pin every mirrored asset, so a tampered or missing asset fails the build deterministically rather than silently. No auth, crypto, or permissions code is involved.
Level of scrutiny
Low-to-moderate. The edits themselves are trivially verifiable string substitutions, and this follows the established pattern from #153 (the prior 20→21 bump). The real validation — does JSC build cleanly under clang 22 across every matrix variant — is provided by the preview-build CI that runs on this PR, not by code review. A grep across Dockerfile*, *.{bash,sh,ts,ps1}, and .github/**/*.yml confirms no lingering clang-21/llvm21/21.1.8 references. windows-release.ps1 needed no edit because it uses the unversioned C:/LLVM install path populated by the workflow's now-updated $llvmVersion.
Other factors
The PR description confirms the new compiler-rt-*-22.1.8 release tags are already published, and explicitly defers the arm64-lto windows-cross question (the LLVM-21 CodeView comment is left as-is) and the downstream Bun bump to follow-ups — both reasonable scoping decisions. The stale llvm_version: '19' workflow-input defaults being cleaned up to '22' is a nice consistency fix; that input appears unused by the reusable workflow's job bodies anyway (the top-level env.LLVM_VERSION and per-Dockerfile ARG defaults are what actually drive the builds). No outstanding reviewer comments.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
Dockerfile (2)
113-116: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winHonor
LLVM_VERSIONhere../llvm.sh 22 allignores the build arg, so--build-arg LLVM_VERSION=21installs the wrong toolchain and laterclang-${LLVM_VERSION}//usr/lib/llvm-${LLVM_VERSION}lookups break. Replace it with./llvm.sh "${LLVM_VERSION}" all.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 113 - 116, Update the LLVM installation RUN command to pass the LLVM_VERSION build argument to llvm.sh instead of hardcoding version 22. Preserve the existing installation flow while ensuring later clang-${LLVM_VERSION} and /usr/lib/llvm-${LLVM_VERSION} references use the installed toolchain.
36-62: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winFail the apt retry loop closed.
break || { ... sleep 15; }returns 0 on the third failed attempt, so theRUNstep can continue even after everyapt-get installfails.dpkg -lonly checkswget,curl,git,python3,ninja-build, andlsb-release, so failures in the other requested packages can slip through.- The mirror swap only happens when
apt-get updateitself fails; an install-time failure still retries the same mirror.Exit nonzero on the last retry and validate the full package set before continuing.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile` around lines 36 - 62, Update the apt installation RUN loop to fail nonzero after the final attempt instead of allowing the retry handler after attempt 3 to succeed. Ensure install-time failures also trigger the fallback mirror before retrying, not only update failures. Replace the partial dpkg validation after the loop with validation covering every package requested by apt-get install, while preserving retries for earlier attempts.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile`:
- Around line 44-47: Update the apt-get install command in the retry loop to
include --no-install-recommends, preserving the existing package installation
and fallback behavior while avoiding unnecessary recommended dependencies.
---
Outside diff comments:
In `@Dockerfile`:
- Around line 113-116: Update the LLVM installation RUN command to pass the
LLVM_VERSION build argument to llvm.sh instead of hardcoding version 22.
Preserve the existing installation flow while ensuring later
clang-${LLVM_VERSION} and /usr/lib/llvm-${LLVM_VERSION} references use the
installed toolchain.
- Around line 36-62: Update the apt installation RUN loop to fail nonzero after
the final attempt instead of allowing the retry handler after attempt 3 to
succeed. Ensure install-time failures also trigger the fallback mirror before
retrying, not only update failures. Replace the partial dpkg validation after
the loop with validation covering every package requested by apt-get install,
while preserving retries for earlier attempts.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9e3c54fa-fa6b-4b17-ab6c-fa721ed60865
📒 Files selected for processing (2)
.github/workflows/build-reusable.ymlDockerfile
| RUN for attempt in 1 2 3; do \ | ||
| ( apt-get update || \ | ||
| ( sed -i 's|http://azure.archive.ubuntu.com/ubuntu|http://archive.ubuntu.com/ubuntu|g' /etc/apt/sources.list && apt-get update ) \ | ||
| ) && apt-get install -y \ |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win
Avoid installing unnecessary APT recommendations.
Add --no-install-recommends unless later build steps require the indirect packages; this keeps the image smaller and reduces its dependency surface.
🧰 Tools
🪛 Hadolint (2.14.0)
[info] 44-44: Avoid additional packages by specifying --no-install-recommends
(DL3015)
[warning] 44-44: Pin versions in apt get install. Instead of apt-get install <package> use apt-get install <package>=<version>
(DL3008)
🪛 Trivy (0.69.3)
[error] 44-63: 'apt-get' missing '--no-install-recommends'
'--no-install-recommends' flag is missed: 'for attempt in 1 2 3; do ( apt-get update || ( sed -i 's|http://azure.archive.ubuntu.com/ubuntu|http://archive.ubuntu.com/ubuntu|g' /etc/apt/sources.list && apt-get update ) ) && apt-get install -y wget curl git python3 python3-pip xz-utils ninja-build software-properties-common apt-transport-https ca-certificates gnupg lsb-release && break || { echo "apt attempt $attempt failed, retrying"; sleep 15; }; done && dpkg -l wget curl git python3 ninja-build lsb-release >/dev/null && rm -rf /var/lib/apt/lists/*'
Rule: DS-0029
(IaC/Dockerfile)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` around lines 44 - 47, Update the apt-get install command in the
retry loop to include --no-install-recommends, preserving the existing package
installation and fallback behavior while avoiding unnecessary recommended
dependencies.
Source: Linters/SAST tools
There was a problem hiding this comment.
No issues found — the 21→22 substitutions look complete and consistent across all Dockerfiles/workflows/scripts, and the apt retry loop's fall-through is guarded by the trailing dpkg -l check. Deferring only because a major compiler version bump for the whole engine is worth a human ack; CI passing is the real signal here.
What was reviewed:
- Grepped for lingering
21.1.8/clang-21/llvm21references in build files — none remain (theLLVM 21's CodeViewcomment is intentionally kept per the description). Dockerfileapt retry loop: if all 3 attempts fail the loop exits 0, butdpkg -l wget ... >/dev/nullfails on missing packages so the layer still errors.fail-fast: falseadditions are pure matrix config;windows-crossalready had it, the rest now match.- compiler-rt asset URLs/tags updated in lockstep with sha256 pins (
ADD --checksum), so a wrong hash fails the build rather than silently using stale bits.
Extended reasoning...
Overview
Mechanical LLVM toolchain bump 21.1.8 → 22.1.8 across 6 Dockerfiles, 3 workflow files, build.ts, and mac-release.bash. Also bumps alpine:3.23→3.24 (required for clang22 packages), updates the mirrored compiler-rt-{darwin,windows} release tags with new sha256 pins, adds fail-fast: false to the remaining matrix jobs, and wraps the base Dockerfile's initial apt-get update && install in a 3-attempt retry with an Acquire::Retries config and a dpkg -l post-check. Follows the same pattern as #153.
Security risks
None introduced. All new external assets (compiler-rt tarballs/libs, LLVM woa64 installer) are fetched over HTTPS from github.com with ADD --checksum=sha256: pins or come from apt.llvm.org via the existing llvm.sh path. No new unpinned downloads, no credential/permission changes.
Level of scrutiny
Medium. The diff itself is a find-replace version bump plus two small CI-reliability tweaks — low review complexity and largely self-verifying (wrong package name / sha256 / missing release asset = immediate build failure). However, a major LLVM release compiling all of JSC can surface codegen or new-warning issues that only show up in the downstream Bun test suite, so a human should be aware this landed rather than have it auto-approved.
Other factors
- Confirmed no stray
21references remain inDockerfile*,*.sh,*.ps1,*.bash,build.ts, or.github/workflows/(the one remainingLLVM 21string is the intentionally-preserved arm64-lto CodeView comment noted in the PR description). - The apt retry loop is correct: on 3 consecutive failures the
forloop itself exits 0 (last command issleep 15), but the chaineddpkg -l wget curl git python3 ninja-build lsb-release >/dev/nullreturns non-zero for uninstalled packages, failing the layer. - The stale
llvm_versioninput default (19) inbuild.yml/build-preview.yml/build-reusable.ymlis now aligned with the envLLVM_VERSION, which was already the effective value used by the Dockerfiles anyway. - No prior
claude[bot]reviews on this PR; only a rate-limited coderabbit walkthrough.
There was a problem hiding this comment.
No issues found — the diff is a mechanical 21→22 substitution plus updated sha256 pins, and I found no leftover 21.1.8/clang-21/llvm21/'19' references in the build infra. Deferring to a human only because a compiler major-version bump affects every shipped binary, so it's worth a quick eye on the full CI matrix before merge.
Checked: all six Dockerfiles, three workflows, build.ts, and mac-release.bash for stray old-version references — none remain (windows-release.ps1 uses unversioned clang-cl from the workflow-installed C:\LLVM, so no change needed there).
Checked: the new Dockerfile apt retry loop — the trailing dpkg -l guard ensures the layer fails if all three attempts miss, so a flaky mirror can't silently produce a broken image.
Checked: fail-fast: false additions — purely additive, no effect on the release job's needs: gating.
Extended reasoning...
Overview
Mechanical LLVM 21.1.8 → 22.1.8 toolchain bump across all build infrastructure: six Dockerfiles (Dockerfile, .android, .freebsd, .macos, .musl, .windows), three GitHub Actions workflows, build.ts, and mac-release.bash. Also bundled: alpine:3.23→3.24 (first release with clang22), fail-fast: false on every matrix job, and a hardened apt retry/mirror-fallback loop in the glibc Dockerfile. No Source/ files are touched.
Security risks
None identified. All new external artifacts (compiler-rt-darwin-22.1.8, compiler-rt-windows-22.1.8) are fetched via ADD --checksum=sha256:… with pinned hashes, and the release tags are published under oven-sh/WebKit per the PR description. The added mirrors.ocf.berkeley.edu ubuntu-ports fallback is a Launchpad-registered mirror serving signed apt indexes, so package integrity is still enforced by apt's GPG verification.
Level of scrutiny
The diff itself is low-risk and follows the established pattern from #153 (the 20→21 bump). A grep across Dockerfile*, *.{bash,sh,ts,ps1}, and .github/**/*.yml for 21.1.8|clang-21|clang\+\+-21|llvm21|clang21|LLVM_VERSION.*21|llvm_version.*(19|21) returns zero hits, so nothing was missed. However, a compiler major-version bump changes codegen for every JSC tier and every shipped Bun binary — the kind of change where confirming the full CI matrix (including the ASAN and LTO variants) is green is more valuable than line-by-line diff review.
Other factors
The CodeRabbit --no-install-recommends nit is pre-existing behavior unrelated to this PR and can be ignored. The apt retry loop's && break || { … } precedence is correct (&& binds tighter than || in POSIX sh), and the post-loop dpkg -l wget curl git python3 ninja-build lsb-release guard means the RUN layer still fails hard if all three attempts fail — so the retry logic can't mask a broken install.
There was a problem hiding this comment.
I didn't find any bugs. Most of this is a mechanical 21→22 version bump, but the new Dockerfile arm64 path (installing bullseye clang-22 on focal via equivs dummy packages for libstdc++-10-dev/libgcc-10-dev/libobjc-10-dev) is a non-trivial cross-distro workaround worth a maintainer glance.
Checked: version strings are consistent across all Dockerfiles/workflows/build.ts/mac-release.bash; compiler-rt asset URLs use ADD --checksum=sha256: pinning; the apt retry loop's trailing dpkg -l guard ensures the RUN fails if all three attempts miss; fail-fast: false additions are benign.
Extended reasoning...
Overview
Toolchain version bump from LLVM 21.1.8 → 22.1.8 across 6 Dockerfiles, 3 GitHub workflows, build.ts, and mac-release.bash. No JSC/WTF/bmalloc source changes. Beyond the s/21/22/ substitutions, it adds: (1) fail-fast: false on every build matrix, (2) an apt retry loop with mirror fallback in Dockerfile, and (3) a new arm64-only install path in Dockerfile that pulls llvm-toolchain-bullseye-22 onto focal, satisfying the Debian-named libstdc++-10-dev/libgcc-10-dev/libobjc-10-dev deps with equivs dummy packages.
Security risks
Low. New downloads (compiler-rt-darwin/windows-22.1.8) are fetched via ADD --checksum=sha256:. The apt.llvm.org key fetch and llvm.sh pipe-to-bash pattern are unchanged from before. The equivs dummies are inert metadata packages. No auth/crypto/runtime code touched.
Level of scrutiny
Build-infrastructure only, so CI is the primary validator — a broken image fails visibly. The mechanical version substitutions and fail-fast: false need essentially no review. The bullseye-on-focal equivs workaround is the one part that merits human judgment: it's a well-commented but unusual approach (vs., say, mirroring the arm64 debs to a release tag like was done for gcc-13), and it relies on bullseye's glibc 2.31 matching focal's. It has a clang-22 --version post-check, so silent breakage is unlikely, but a maintainer should confirm they're comfortable with the approach.
Other factors
The apt retry loop correctly guards against the "all attempts failed but loop exited 0" case via the trailing && dpkg -l ... >/dev/null. The CodeRabbit --no-install-recommends comment is a pre-existing linter nit unrelated to this PR's intent. PR description notes the compiler-rt-22.1.8 release tags are already published, which the SHA256 pins would catch if untrue.
There was a problem hiding this comment.
I didn't find any bugs, but deferring to a human on this one — beyond the mechanical 21→22 substitutions, the Dockerfile arm64 path is a substantial new workaround (bullseye LLVM packages on focal via equivs dummies + SHA-pinned Debian libz3 .debs, dropping lldb-22), and it governs the toolchain that produces every Linux release artifact.
What was reviewed:
- Consistency of the 21→22 rename across all Dockerfiles, workflows,
build.ts,mac-release.bash— no stray21/21.1.8references remain. - The apt retry/mirror-fallback loop in
Dockerfile— the trailingdpkg -lguard correctly fails the layer if all three attempts miss. fail-fast: falseadditions — purely additive, matches the existingwindows-crossjob.
Extended reasoning...
Overview
Bumps the LLVM toolchain from 21.1.8 to 22.1.8 across every build surface: six Dockerfiles, three GitHub Actions workflows, build.ts, and mac-release.bash. Most of the diff is a mechanical 21→22 rename plus updated SHA-256 pins for the mirrored compiler-rt-{darwin,windows}-22.1.8 release assets and an Alpine 3.23→3.24 base bump.
The non-mechanical portion is in Dockerfile: because apt.llvm.org stopped publishing focal arm64 binaries for LLVM 22, the arm64 branch now sources the bullseye repo instead, papers over three Debian-named Depends: (libstdc++-10-dev/libgcc-10-dev/libobjc-10-dev) with equivs dummies, installs bullseye's libz3-4/libz3-dev .debs directly (SHA-256 pinned) to satisfy libLLVM's real DT_NEEDED, and omits lldb-22 (whose python3.9 dep is unsatisfiable on focal). The apt bootstrap layer also gained a mirror-swap retry loop for both amd64 and arm64.
Additionally, fail-fast: false is added to five matrix strategies in build-reusable.yml.
Security risks
Low. New external fetches (deb.debian.org libz3 .debs, oven-sh/WebKit compiler-rt release assets) are all SHA-256 pinned. The apt.llvm.org key is fetched over HTTPS as before. No secrets, permissions, or auth changes. The equivs dummy packages are inert placeholders. The one thing worth a human eye is confirming the bullseye-on-focal approach doesn't accidentally shift the glibc/libstdc++ floor of produced binaries — the PR's inline comment claims verification (libc6 stays at 2.31, tops out at GLIBC_2.17), but I can't independently validate that.
Level of scrutiny
Medium-high. This is build/CI infrastructure, not runtime code, so a mistake fails loudly at image-build or compile time rather than shipping a silent bug. However, it defines the compiler used for every published Bun WebKit artifact, and the arm64 path is a creative cross-distro packaging workaround with several moving parts (equivs, direct .deb installs, a deliberately dangling /usr/bin/lldb symlink). That's the kind of change a maintainer should sign off on and confirm passes the full CI matrix before merge.
Other factors
- Grepped the touched build files for leftover
21/21.1.8/clang-21/llvm21references — none remain. - The CodeRabbit
--no-install-recommendsnit is a pre-existing pattern unrelated to this PR. - The
bun-webkit-windows-amd64-baseline-ltomatrix entry visible in the diff context is unchanged by this PR (context lines only). - The PR description notes the
compiler-rt-*-22.1.8release tags are already published; I can't verify the SHA-256 values match the uploaded assets.
Preview Builds
|
… WebKit pin - .buildkite/Dockerfile arm64: install bullseye libz3-4/libz3-dev (sha256-pinned) and drop lldb-22, matching oven-sh/WebKit@5c5e1cdf. libz3.so.4 is a real DT_NEEDED of libLLVM so an equivs dummy can't cover it; the two bullseye .debs only need libc6 (>= 2.30) / libstdc++6 (>= 9), which focal satisfies. - .buildkite/ci.mjs: alpine 3.23 -> 3.24 (3.23 has no clang22). - scripts/bootstrap.sh apk: tag alpine edge for the llvm/clang/lld packages so CI musl images get 22.1.8 instead of 3.24's 22.1.3. musl is 1.2.6-r2 in both, so edge's binaries run on 3.24. - scripts/bootstrap.{sh,ps1}: bump Version markers to 41 / 23 (main caught up to 39 / 22 and another branch is at 40). - scripts/build/deps/webkit.ts: pin to the LLVM-22-built preview release autobuild-preview-pr-296-1614a889 (oven-sh/WebKit#296, synced with WebKit main and building musl with 22.1.8 via edge).
…ebKit pin - .buildkite/Dockerfile arm64: install bullseye libz3-4/libz3-dev (sha256-pinned) and drop lldb-22, matching oven-sh/WebKit@5c5e1cdf. libz3.so.4 is a real DT_NEEDED of libLLVM so an equivs dummy can't cover it; the two bullseye .debs only need libc6 (>= 2.30) / libstdc++6 (>= 9), which focal satisfies. - .buildkite/ci.mjs: alpine 3.23 -> 3.24 (3.23 has no clang22). - scripts/bootstrap.sh apk: tag alpine edge for the llvm/clang/lld packages so CI musl images get 22.1.8 instead of 3.24's 22.1.3. musl is 1.2.6-r2 in both, so edge's binaries run on 3.24. - scripts/bootstrap.{sh,ps1}: bump Version markers to 41 / 23 (main caught up to 39 / 22 and another branch is at 40). - scripts/build/deps/webkit.ts: pin to the LLVM-22-built preview release autobuild-preview-pr-296-1614a889 (oven-sh/WebKit#296, synced with WebKit main and building musl with 22.1.8 via edge).
There was a problem hiding this comment.
I didn't find any bugs, and the preview build passed across all variants. Deferring to a human because beyond the mechanical 21→22 bumps, this introduces two non-trivial pieces of build infrastructure worth a maintainer's eye: the arm64 focal path in Dockerfile now pulls LLVM 22 from the Debian bullseye repo with equivs-dummy deps and directly-installed bullseye libz3 .debs, and Dockerfile.musl pins clang22/llvm22/lld22 to Alpine edge on a 3.24 base.
What was reviewed:
- Version-string consistency across all 6 Dockerfiles, 3 workflows,
build.ts, andmac-release.bash— no stray21references left. - The new apt retry loop in
Dockerfile: the&& break || { ... }/dpkg -lpost-check correctly fails the layer if all 3 attempts miss. Dockerfile.musl@edgetagging keeps non-LLVM packages on 3.24 stable; the previous unversionedlld/lld-devare now correctlylld22@edge/lld22-dev@edge.fail-fast: falseadditions only affect matrix cancellation behavior, not release gating (thereleasejob stillneeds:every build job).
Extended reasoning...
Overview
This PR upgrades the LLVM toolchain from 21.1.8 to 22.1.8 across the entire build matrix: 6 Dockerfiles (Dockerfile, .android, .freebsd, .macos, .musl, .windows), 3 GitHub Actions workflows, build.ts, and mac-release.bash. Most changes are mechanical s/21/22/ substitutions plus updated SHA-256 pins for the new compiler-rt-{darwin,windows}-22.1.8 release assets. However, two areas contain substantive new logic:
Dockerfile(glibc/focal, arm64 branch): apt.llvm.org stopped publishing focal arm64 binaries for LLVM 22, so the arm64 path now sources fromllvm-toolchain-bullseye-22, satisfies Debian-named deps (libstdc++-10-dev,libgcc-10-dev,libobjc-10-dev) with equivs dummies, installs bullseye'slibz3-4/libz3-dev.debs directly (SHA-256-pinned), and installs an explicit package list instead ofllvm.sh 22 all. The apt bootstrap also gained a 3-attempt retry loop with mirror-swapping (Azure→canonical for amd64, ports.ubuntu.com→OCF for arm64) plusAcquire::Retries "5".Dockerfile.musl: Alpine base bumped 3.23→3.24, and clang22/llvm22/lld22 packages are now pulled from a tagged@edgerepo (3.24 ships 22.1.3; edge has 22.1.8).
The workflows also add fail-fast: false to five matrix strategies so one variant's failure doesn't cancel siblings.
Security risks
Low. New external fetches are either SHA-256-pinned (libz3-4/libz3-dev .debs, compiler-rt release assets) or come from GPG-signed apt repos (apt.llvm.org bullseye via the same llvm-snapshot.gpg.key, Alpine edge via apk's built-in signing). The apt retry loop's fallback mirror mirrors.ocf.berkeley.edu is a Launchpad-registered ubuntu-ports mirror and packages are still verified against Ubuntu's Release signatures. No changes to auth, permissions, or runtime code paths — this is purely build-time toolchain provisioning.
Level of scrutiny
Medium-high. A compiler toolchain bump affects every published Bun WebKit artifact. The preview build (autobuild-preview-pr-296-5c5e1cdf) succeeded across the full matrix, which is the primary validation for build-infra changes. But the arm64 bullseye-on-focal workaround is a novel cross-distro packaging approach with a documented-but-subtle glibc-floor invariant, and the Alpine edge pinning relies on musl ABI compatibility between 3.24 and edge holding. These are reasonable, well-commented engineering decisions — but they're decisions, not mechanical bumps, and a maintainer should confirm they're the preferred approach vs. alternatives (e.g., waiting for focal arm64 packages, bumping the focal base image, or mirroring the arm64 .debs to a GitHub release like the gcc-13 pattern already used elsewhere in this file).
Other factors
- The only outstanding reviewer comment is a CodeRabbit "trivial" nitpick about
--no-install-recommendson a pre-existing apt line — unrelated to this PR's substance and safe to ignore. - No prior
claude[bot]reviews on this PR. - The PR description explicitly notes the
arm64-ltowindows-cross CodeView comment was left stale intentionally, and that the Bun-side bump lands separately — both reasonable. bun-webkit-windows-amd64-baseline-ltois built bywindows-crossbut not downloaded/uploaded in thereleasejob — that's pre-existing behavior, not introduced here.
One arm64 job's transient ports.ubuntu.com connection failure was cancelling all 12 Linux variants. windows-cross already had this; apply it to linux, linux-musl, macos-cross, freebsd, and linux-android too.
…ndex apt-get update exits 0 with only a W: warning when an InRelease fetch fails, so the azure->archive fallback never fired and the subsequent install died with 'no installation candidate'. arm64 (ports.ubuntu.com) hit this on two consecutive runs. Add Acquire::Retries and wrap the update+install in a 3-attempt loop, then verify with dpkg -l.
… is down ports.ubuntu.com (the only canonical arm64 archive) went fully dark for 10+ minutes during this PR's CI, defeating the 3-attempt retry loop. On a failed attempt, swap arm64 to mirrors.ocf.berkeley.edu/ubuntu-ports (Launchpad-registered) the same way amd64 already swaps azure->archive.
apt.llvm.org's llvm-toolchain-focal-22 has no arm64 binaries (only the Architecture:all doc/example packages). llvm-toolchain-bullseye-22 has the full arm64 set and is built against glibc 2.31 (same as focal), so the binaries run on ubuntu:20.04. The bullseye clang-22 package declares Depends on Debian's libstdc++-10-dev/libgcc-10-dev/libobjc-10-dev; those are stubbed with equivs since we use gcc-13's libstdc++ via the PPA and set its include paths explicitly. amd64 keeps using llvm.sh against focal unchanged.
The bullseye clang-22 packages don't install on the focal base: libllvm22 : Depends: libz3-4 (>= 4.8.10) but 4.8.7-4build1 is to be installed lldb-22 : Depends: python3-lldb-22 but it is not going to be installed focal only ships libz3 4.8.7, and llvm-22-dev additionally wants the matching libz3-dev. equivs dummies don't work for z3 the way they do for libstdc++-10-dev: libz3.so.4 is a real DT_NEEDED of libLLVM, so a dummy would leave clang-22 unable to start. Install the two bullseye .debs directly, SHA-256-pinned, instead of adding deb.debian.org as an apt source, so apt can't pull any other Debian package into the image -- in particular a libc6/libstdc++6 that would move the glibc floor. Both only declare libc6 (>= 2.30) / libstdc++6 (>= 9), which focal already satisfies. python3-lldb-22 needs python3 (>= 3.9~) (<< 3.10) and focal ships 3.8, so lldb can't be installed here without pulling in Debian's python3 stack. Nothing in the build uses lldb, so arm64 omits it. Verified on a native arm64 focal container with the real gcc-13 debs: clang-22 22.1.8 installs and runs, libc6 stays at 2.31-0ubuntu9.18, and a clang++-22 -stdlib=libstdc++ binary still tops out at GLIBC_2.17.
alpine 3.24's main repo has clang22/llvm22/lld22 at 22.1.3; edge has 22.1.8. Tag the edge main repo and pull only the LLVM packages from it (musl is 1.2.6-r2 in both, so edge's binaries run on the 3.24 base). Everything else stays on 3.24 stable.
1614a88 to
6144f51
Compare
There was a problem hiding this comment.
I didn't find any bugs, and the preview builds for both commits succeeded end-to-end, but I'd like a human to sign off on the arm64 focal→bullseye LLVM install workaround and the Alpine @edge pinning before this lands.
What was reviewed:
- Version-string consistency across all 6 Dockerfiles, 3 workflows,
build.ts, andmac-release.bash— no stray21references left. Dockerfilearm64 branch: equivs dummies + SHA-pinned bullseye libz3 debs; the retry loop's&& break || { … }/ trailingdpkg -lguard correctly fails the layer if all 3 attempts miss.Dockerfile.musl:lld/lld-devcorrectly renamed tolld22@edge/lld22-dev@edgealongside the other tagged packages.fail-fast: falseadditions are benign and don't affect thereleasejob'sneeds:gating.
Extended reasoning...
Overview
This PR bumps the LLVM toolchain from 21.1.8 to 22.1.8 across all build infrastructure: six Dockerfiles (glibc, musl, android, freebsd, macos, windows), three GitHub workflows, build.ts, and mac-release.bash. Beyond the mechanical 21→22 substitutions, it introduces three non-trivial pieces: (1) a ~60-line arm64-only branch in Dockerfile that installs LLVM 22 from apt.llvm.org's bullseye repo onto the focal base (because focal arm64 binaries were dropped upstream), papering over Debian-vs-Ubuntu dependency naming with equivs dummies and SHA-pinned bullseye libz3 .debs; (2) an Alpine @edge repo tag in Dockerfile.musl so clang22/llvm22/lld22 come from edge (22.1.8) while everything else stays on 3.24 stable; (3) a reworked apt retry loop with mirror fallback for both amd64 and arm64. It also adds fail-fast: false to five matrix jobs and updates SHA256 pins for the mirrored compiler-rt-{darwin,windows}-22.1.8 assets.
Security risks
Low. All new external downloads (bullseye libz3 .debs, compiler-rt tarballs/libs) are SHA256-pinned. The apt.llvm.org GPG key is fetched over HTTPS and installed to trusted.gpg.d. The Alpine @edge repo is an official Alpine mirror. No auth, crypto, or permission code is touched — this is purely build-image plumbing.
Level of scrutiny
Moderate-to-high. While version bumps are nominally mechanical, this one changes the compiler that produces every shipped artifact, and the arm64 workaround is genuinely intricate: it mixes Debian bullseye packages onto an Ubuntu focal base with fake dependency satisfiers, relying on the two distros sharing glibc 2.31. The comment block is thorough and the preview builds prove it works today, but this is exactly the kind of packaging fragility a maintainer should consciously accept rather than have auto-approved. The Alpine @edge tag is similar — edge is rolling, and the "musl is the same version in both" assumption in the comment could drift.
Other factors
Strong signal that this is correct: the preview-build workflow produced release artifacts for both 5c5e1cdf and 1614a889, meaning all ~40 matrix variants (linux glibc/musl × x64/arm64 × debug/release/lto/asan, macos-cross, windows-cross, freebsd, android) built and the release job (which needs: every build job) completed. That's near-conclusive for "does it build." What it doesn't validate is runtime codegen correctness under LLVM 22, which will only surface when Bun links against these artifacts — the PR description notes that lands separately with [build images]. The CodeRabbit --no-install-recommends nit is pre-existing style and out of scope. Given the toolchain-wide impact and the bespoke cross-distro packaging, deferring to a human is the safer call.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
Dockerfile.windows (1)
128-149: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
compiler-rt-windows-22.1.8is hardcoded 6 times with no backingARG.Unlike
LLVM_VERSION, there's noARGfor the compiler-rt release tag here, so this literal string is repeated across the builtins and ASAN artifact URLs. See consolidated comment for the shared fix.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.windows` around lines 128 - 149, Add a dedicated ARG for the compiler-rt Windows release tag near the existing LLVM_VERSION configuration, then replace every compiler-rt-windows-22.1.8 occurrence in the builtins and ASAN ADD URLs with that ARG. Keep the current artifact paths and checksums unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-reusable.yml:
- Around line 271-272: Update the LLVM ARM64 download flow using $llvmVersion so
LLVM-22.1.8-woa64.exe is verified with the publisher’s checksum or attestation
immediately after Invoke-WebRequest and before 7-Zip extraction. Fail the
workflow when verification fails, and only extract the verified installer.
In `@Dockerfile`:
- Around line 147-177: Replace every hardcoded LLVM version literal in the
arm64/bullseye installation block with the existing LLVM_VERSION build argument,
including the apt suite name, LLVM/Clang package names, llvm.sh invocation, and
clang version check. Keep package naming and installation behavior unchanged
while ensuring changing LLVM_VERSION updates the entire block.
In `@Dockerfile.macos`:
- Around line 50-51: Update the Dockerfile macOS artifact download using
COMPILER_RT_DARWIN_TAG so the ADD filename derives its version from that
argument instead of hardcoding 22.1.8. Keep the existing checksum validation and
artifact path behavior unchanged.
In `@Dockerfile.musl`:
- Around line 23-25: Combine the repository update, apk index refresh, and
package installation into a single RUN instruction in Dockerfile.musl. Keep the
existing `@edge` repository configuration and package list unchanged while
removing the separate apk update layer.
---
Outside diff comments:
In `@Dockerfile.windows`:
- Around line 128-149: Add a dedicated ARG for the compiler-rt Windows release
tag near the existing LLVM_VERSION configuration, then replace every
compiler-rt-windows-22.1.8 occurrence in the builtins and ASAN ADD URLs with
that ARG. Keep the current artifact paths and checksums unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3cd08c75-12c3-4e3c-9e15-bb936bf18c27
📒 Files selected for processing (11)
.github/workflows/build-preview.yml.github/workflows/build-reusable.yml.github/workflows/build.ymlDockerfileDockerfile.androidDockerfile.freebsdDockerfile.macosDockerfile.muslDockerfile.windowsbuild.tsmac-release.bash
| # Use LLVM 22 for ARM64 - has better Windows ARM64 support and fixes SEH unwind bugs | ||
| $llvmVersion = "22.1.8" |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
tmp_dir="$(mktemp -d)"
gh release download llvmorg-22.1.8 \
--repo llvm/llvm-project \
--pattern 'LLVM-22.1.8-woa64.exe*' \
--dir "$tmp_dir"
gh attestation verify \
--repo llvm/llvm-project \
"$tmp_dir/LLVM-22.1.8-woa64.exe"Repository: oven-sh/WebKit
Length of output: 152
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n -C 4 'LLVM-22.1.8-woa64\.exe|attestation|checksum|extract|Expand-Archive|Invoke-WebRequest|curl|wget' .github/workflows/build-reusable.ymlRepository: oven-sh/WebKit
Length of output: 1270
Verify the LLVM ARM64 installer before extracting it.
Invoke-WebRequest downloads LLVM-22.1.8-woa64.exe and 7-Zip extracts it immediately. Add checksum or attestation verification before extraction so a tampered release asset can’t run in CI.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-reusable.yml around lines 271 - 272, Update the LLVM
ARM64 download flow using $llvmVersion so LLVM-22.1.8-woa64.exe is verified with
the publisher’s checksum or attestation immediately after Invoke-WebRequest and
before 7-Zip extraction. Fail the workflow when verification fails, and only
extract the verified installer.
Source: MCP tools
| ARG LIBZ3_VERSION=4.8.10-1 | ||
| ARG LIBZ3_SHA256_arm64=ae1ea58ecfdd4b5ec53d734e60ac2df37fddb11888b7730a19335f1a9b09f489 | ||
| ARG LIBZ3_DEV_SHA256_arm64=4739e62c1f39c35f2382f15347b588245a71bd12c8628a8caa6639fdc1774b6c | ||
| RUN wget -qO /etc/apt/trusted.gpg.d/apt.llvm.org.asc https://apt.llvm.org/llvm-snapshot.gpg.key \ | ||
| && if [ "$TARGETARCH" = "arm64" ]; then \ | ||
| echo "deb https://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-22 main" > /etc/apt/sources.list.d/llvm.list \ | ||
| && apt-get update \ | ||
| && apt-get install -y --no-install-recommends equivs \ | ||
| && for p in libstdc++-10-dev libgcc-10-dev libobjc-10-dev; do \ | ||
| printf 'Section: misc\nPriority: optional\nStandards-Version: 3.9.2\nPackage: %s\nVersion: 99\nDescription: dummy for bullseye clang-22 dep\n' "$p" > /tmp/$p.ctl \ | ||
| && (cd /tmp && equivs-build $p.ctl && dpkg -i ${p}_99_all.deb && rm -f $p.ctl ${p}_99_all.deb); \ | ||
| done \ | ||
| && curl -fsSL --retry 5 --retry-connrefused \ | ||
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-4_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-4.deb \ | ||
| && curl -fsSL --retry 5 --retry-connrefused \ | ||
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-dev_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-dev.deb \ | ||
| && echo "${LIBZ3_SHA256_arm64} /tmp/libz3-4.deb" | sha256sum -c - \ | ||
| && echo "${LIBZ3_DEV_SHA256_arm64} /tmp/libz3-dev.deb" | sha256sum -c - \ | ||
| && dpkg -i /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | ||
| && rm -f /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | ||
| && apt-get install -y --no-install-recommends \ | ||
| clang-22 lld-22 llvm-22 llvm-22-dev llvm-22-tools llvm-22-runtime \ | ||
| llvm-22-linker-tools libllvm22 libclang-cpp22 libclang1-22 \ | ||
| libclang-common-22-dev libclang-rt-22-dev liblld-22 clangd-22; \ | ||
| else \ | ||
| wget https://apt.llvm.org/llvm.sh \ | ||
| && chmod +x llvm.sh \ | ||
| && ./llvm.sh 22 all \ | ||
| && rm llvm.sh; \ | ||
| fi \ | ||
| && clang-22 --version \ |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Hardcoded 22 throughout the arm64/bullseye install block instead of ${LLVM_VERSION}.
ARG LLVM_VERSION is available in this stage (line 22) and is used consistently everywhere else in the file (e.g. lines 193, 230, 245-249), but this block hardcodes the literal 22 in the bullseye suite name (line 152), all ~14 package names (lines 168-170), the llvm.sh invocation (line 174), and the version-check (line 177). This is exactly the kind of duplication that forced manual edits across this file for the 21→22 bump; the next bump will need the same manual sweep instead of just changing the ARG default.
♻️ Proposed fix (illustrative, non-exhaustive)
- echo "deb https://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-22 main" > /etc/apt/sources.list.d/llvm.list \
+ echo "deb https://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-${LLVM_VERSION} main" > /etc/apt/sources.list.d/llvm.list \
...
&& apt-get install -y --no-install-recommends \
- clang-22 lld-22 llvm-22 llvm-22-dev llvm-22-tools llvm-22-runtime \
- llvm-22-linker-tools libllvm22 libclang-cpp22 libclang1-22 \
- libclang-common-22-dev libclang-rt-22-dev liblld-22 clangd-22; \
+ clang-${LLVM_VERSION} lld-${LLVM_VERSION} llvm-${LLVM_VERSION} llvm-${LLVM_VERSION}-dev llvm-${LLVM_VERSION}-tools llvm-${LLVM_VERSION}-runtime \
+ llvm-${LLVM_VERSION}-linker-tools libllvm${LLVM_VERSION} libclang-cpp${LLVM_VERSION} libclang1-${LLVM_VERSION} \
+ libclang-common-${LLVM_VERSION}-dev libclang-rt-${LLVM_VERSION}-dev liblld-${LLVM_VERSION} clangd-${LLVM_VERSION}; \
else \
wget https://apt.llvm.org/llvm.sh \
&& chmod +x llvm.sh \
- && ./llvm.sh 22 all \
+ && ./llvm.sh ${LLVM_VERSION} all \
&& rm llvm.sh; \
fi \
- && clang-22 --version \
+ && clang-${LLVM_VERSION} --version \📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ARG LIBZ3_VERSION=4.8.10-1 | |
| ARG LIBZ3_SHA256_arm64=ae1ea58ecfdd4b5ec53d734e60ac2df37fddb11888b7730a19335f1a9b09f489 | |
| ARG LIBZ3_DEV_SHA256_arm64=4739e62c1f39c35f2382f15347b588245a71bd12c8628a8caa6639fdc1774b6c | |
| RUN wget -qO /etc/apt/trusted.gpg.d/apt.llvm.org.asc https://apt.llvm.org/llvm-snapshot.gpg.key \ | |
| && if [ "$TARGETARCH" = "arm64" ]; then \ | |
| echo "deb https://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-22 main" > /etc/apt/sources.list.d/llvm.list \ | |
| && apt-get update \ | |
| && apt-get install -y --no-install-recommends equivs \ | |
| && for p in libstdc++-10-dev libgcc-10-dev libobjc-10-dev; do \ | |
| printf 'Section: misc\nPriority: optional\nStandards-Version: 3.9.2\nPackage: %s\nVersion: 99\nDescription: dummy for bullseye clang-22 dep\n' "$p" > /tmp/$p.ctl \ | |
| && (cd /tmp && equivs-build $p.ctl && dpkg -i ${p}_99_all.deb && rm -f $p.ctl ${p}_99_all.deb); \ | |
| done \ | |
| && curl -fsSL --retry 5 --retry-connrefused \ | |
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-4_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-4.deb \ | |
| && curl -fsSL --retry 5 --retry-connrefused \ | |
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-dev_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-dev.deb \ | |
| && echo "${LIBZ3_SHA256_arm64} /tmp/libz3-4.deb" | sha256sum -c - \ | |
| && echo "${LIBZ3_DEV_SHA256_arm64} /tmp/libz3-dev.deb" | sha256sum -c - \ | |
| && dpkg -i /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | |
| && rm -f /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | |
| && apt-get install -y --no-install-recommends \ | |
| clang-22 lld-22 llvm-22 llvm-22-dev llvm-22-tools llvm-22-runtime \ | |
| llvm-22-linker-tools libllvm22 libclang-cpp22 libclang1-22 \ | |
| libclang-common-22-dev libclang-rt-22-dev liblld-22 clangd-22; \ | |
| else \ | |
| wget https://apt.llvm.org/llvm.sh \ | |
| && chmod +x llvm.sh \ | |
| && ./llvm.sh 22 all \ | |
| && rm llvm.sh; \ | |
| fi \ | |
| && clang-22 --version \ | |
| ARG LIBZ3_VERSION=4.8.10-1 | |
| ARG LIBZ3_SHA256_arm64=ae1ea58ecfdd4b5ec53d734e60ac2df37fddb11888b7730a19335f1a9b09f489 | |
| ARG LIBZ3_DEV_SHA256_arm64=4739e62c1f39c35f2382f15347b588245a71bd12c8628a8caa6639fdc1774b6c | |
| RUN wget -qO /etc/apt/trusted.gpg.d/apt.llvm.org.asc https://apt.llvm.org/llvm-snapshot.gpg.key \ | |
| && if [ "$TARGETARCH" = "arm64" ]; then \ | |
| echo "deb https://apt.llvm.org/bullseye/ llvm-toolchain-bullseye-${LLVM_VERSION} main" > /etc/apt/sources.list.d/llvm.list \ | |
| && apt-get update \ | |
| && apt-get install -y --no-install-recommends equivs \ | |
| && for p in libstdc++-10-dev libgcc-10-dev libobjc-10-dev; do \ | |
| printf 'Section: misc\nPriority: optional\nStandards-Version: 3.9.2\nPackage: %s\nVersion: 99\nDescription: dummy for bullseye clang-22 dep\n' "$p" > /tmp/$p.ctl \ | |
| && (cd /tmp && equivs-build $p.ctl && dpkg -i ${p}_99_all.deb && rm -f $p.ctl ${p}_99_all.deb); \ | |
| done \ | |
| && curl -fsSL --retry 5 --retry-connrefused \ | |
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-4_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-4.deb \ | |
| && curl -fsSL --retry 5 --retry-connrefused \ | |
| "http://deb.debian.org/debian/pool/main/z/z3/libz3-dev_${LIBZ3_VERSION}_arm64.deb" -o /tmp/libz3-dev.deb \ | |
| && echo "${LIBZ3_SHA256_arm64} /tmp/libz3-4.deb" | sha256sum -c - \ | |
| && echo "${LIBZ3_DEV_SHA256_arm64} /tmp/libz3-dev.deb" | sha256sum -c - \ | |
| && dpkg -i /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | |
| && rm -f /tmp/libz3-4.deb /tmp/libz3-dev.deb \ | |
| && apt-get install -y --no-install-recommends \ | |
| clang-${LLVM_VERSION} lld-${LLVM_VERSION} llvm-${LLVM_VERSION} llvm-${LLVM_VERSION}-dev llvm-${LLVM_VERSION}-tools llvm-${LLVM_VERSION}-runtime \ | |
| llvm-${LLVM_VERSION}-linker-tools libllvm${LLVM_VERSION} libclang-cpp${LLVM_VERSION} libclang1-${LLVM_VERSION} \ | |
| libclang-common-${LLVM_VERSION}-dev libclang-rt-${LLVM_VERSION}-dev liblld-${LLVM_VERSION} clangd-${LLVM_VERSION}; \ | |
| else \ | |
| wget https://apt.llvm.org/llvm.sh \ | |
| && chmod +x llvm.sh \ | |
| && ./llvm.sh ${LLVM_VERSION} all \ | |
| && rm llvm.sh; \ | |
| fi \ | |
| && clang-${LLVM_VERSION} --version \ |
🧰 Tools
🪛 Hadolint (2.14.0)
[info] 150-150: Avoid use of wget without progress bar. Use wget --progress=dot:giga <url>. Or consider using -q or -nv (shorthands for --quiet or --no-verbose).
(DL3047)
[warning] 150-150: Pin versions in apt get install. Instead of apt-get install <package> use apt-get install <package>=<version>
(DL3008)
[warning] 150-150: Either use Wget or Curl but not both
(DL4001)
[warning] 150-150: Use WORKDIR to switch to a directory
(DL3003)
[warning] 150-150: Set the SHELL option -o pipefail before RUN with a pipe in it. If you are using /bin/sh in an alpine image or if your shell is symlinked to busybox then consider explicitly setting your SHELL to /bin/ash, or disable this check
(DL4006)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile` around lines 147 - 177, Replace every hardcoded LLVM version
literal in the arm64/bullseye installation block with the existing LLVM_VERSION
build argument, including the apt suite name, LLVM/Clang package names, llvm.sh
invocation, and clang version check. Keep package naming and installation
behavior unchanged while ensuring changing LLVM_VERSION updates the entire
block.
| ARG COMPILER_RT_DARWIN_TAG="compiler-rt-darwin-22.1.8" | ||
| ARG COMPILER_RT_DARWIN_SHA256="2a6cb08a41880f20f882205d567ee0676ced7db9aaeccfa2e26643d94eca23b7" |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Version 22.1.8 is duplicated between COMPILER_RT_DARWIN_TAG and the hardcoded filename.
COMPILER_RT_DARWIN_TAG already encodes the version, but the ADD filename at line 116 separately hardcodes 22.1.8 again. If a future bump only updates the tag ARG, the filename would silently mismatch (404 on the wrong artifact). See consolidated comment.
Also applies to: 116-116
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile.macos` around lines 50 - 51, Update the Dockerfile macOS artifact
download using COMPILER_RT_DARWIN_TAG so the ADD filename derives its version
from that argument instead of hardcoding 22.1.8. Keep the existing checksum
validation and artifact path behavior unchanged.
| RUN echo "@edge https://dl-cdn.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories | ||
| RUN apk update | ||
| RUN apk add --no-cache cmake make clang21 clang21-static clang21-dev llvm21-dev llvm21-static musl-dev git lld libgcc gcc g++ libstdc++ build-base lld-dev llvm21-libs libc-dev xz zlib zlib-dev libxml2 libxml2-dev | ||
| RUN apk add --no-cache cmake make clang22@edge clang22-static@edge clang22-dev@edge llvm22-dev@edge llvm22-static@edge lld22@edge lld22-dev@edge llvm22-libs@edge musl-dev git libgcc gcc g++ libstdc++ build-base libc-dev xz zlib zlib-dev libxml2 libxml2-dev |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win
Split apk update/apk add into separate RUN layers.
Static analysis flags this pattern (Trivy DS-0017, Hadolint DL3059): with apk update cached in its own layer, a later rebuild that only touches the apk add layer risks reusing a stale index if Docker's layer cache isn't fully invalidated. Since the new @edge repo line was just added right above, consolidating into one RUN removes this risk cleanly.
♻️ Proposed fix
RUN echo "`@edge` https://dl-cdn.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories
-RUN apk update
-RUN apk add --no-cache cmake make clang22@edge clang22-static@edge clang22-dev@edge llvm22-dev@edge llvm22-static@edge lld22@edge lld22-dev@edge llvm22-libs@edge musl-dev git libgcc gcc g++ libstdc++ build-base libc-dev xz zlib zlib-dev libxml2 libxml2-dev
+RUN apk update && apk add --no-cache cmake make clang22@edge clang22-static@edge clang22-dev@edge llvm22-dev@edge llvm22-static@edge lld22@edge lld22-dev@edge llvm22-libs@edge musl-dev git libgcc gcc g++ libstdc++ build-base libc-dev xz zlib zlib-dev libxml2 libxml2-dev📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| RUN echo "@edge https://dl-cdn.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories | |
| RUN apk update | |
| RUN apk add --no-cache cmake make clang21 clang21-static clang21-dev llvm21-dev llvm21-static musl-dev git lld libgcc gcc g++ libstdc++ build-base lld-dev llvm21-libs libc-dev xz zlib zlib-dev libxml2 libxml2-dev | |
| RUN apk add --no-cache cmake make clang22@edge clang22-static@edge clang22-dev@edge llvm22-dev@edge llvm22-static@edge lld22@edge lld22-dev@edge llvm22-libs@edge musl-dev git libgcc gcc g++ libstdc++ build-base libc-dev xz zlib zlib-dev libxml2 libxml2-dev | |
| RUN echo "`@edge` https://dl-cdn.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories | |
| RUN apk update && apk add --no-cache cmake make clang22@edge clang22-static@edge clang22-dev@edge llvm22-dev@edge llvm22-static@edge lld22@edge lld22-dev@edge llvm22-libs@edge musl-dev git libgcc gcc g++ libstdc++ build-base libc-dev xz zlib zlib-dev libxml2 libxml2-dev |
🧰 Tools
🪛 Hadolint (2.14.0)
[info] 24-24: Multiple consecutive RUN instructions. Consider consolidation.
(DL3059)
[warning] 25-25: Pin versions in apk add. Instead of apk add <package> use apk add <package>=<version>
(DL3018)
[info] 25-25: Multiple consecutive RUN instructions. Consider consolidation.
(DL3059)
🪛 Trivy (0.72.0)
[error] 24-24: 'RUN update' instruction alone
The instruction 'RUN update' should always be followed by ' install' in the same RUN statement.
Rule: DS-0017
(IaC/Dockerfile)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile.musl` around lines 23 - 25, Combine the repository update, apk
index refresh, and package installation into a single RUN instruction in
Dockerfile.musl. Keep the existing `@edge` repository configuration and package
list unchanged while removing the separate apk update layer.
Source: Linters/SAST tools
- scripts/bootstrap.{sh,ps1}: Version 41->42 / 23->24 (main caught up to
41/22 via #34782).
- scripts/bootstrap.sh: alpine_sysroot_version 3.23 -> 3.24.
- scripts/build/deps/webkit.ts: pin to autobuild-preview-pr-296-6144f510
(oven-sh/WebKit#296 rebased onto main c9296e353e).
- src/jsc/bindings/highway_{json,sourcemap}.cpp: disable scalable
HWY_SVE/HWY_SVE2. clang >= 22 stops marking them HWY_BROKEN in
detect_targets.h, so foreach_target compiles for them, but BitsFromMask
only exists for the fixed-size SVE_256/SVE2_128 variants.
2 participants
Bumps the LLVM toolchain across all build Dockerfiles and workflows from 21.1.8 to 22.1.8.
Changes
Dockerfile,Dockerfile.{android,freebsd,macos,musl,windows}:LLVM_VERSION21 -> 22Dockerfile.musl:alpine:3.23->alpine:3.24(first release withclang22/llvm22/lld22)Dockerfile.macos:compiler-rt-darwin-22.1.8release (new tag, extracted fromLLVM-22.1.8-macOS-ARM64.tar.xz)Dockerfile.windows:compiler-rt-windows-22.1.8release (new tag, extracted fromclang+llvm-22.1.8-{x86_64,aarch64}-pc-windows-msvc.tar.xz)build-reusable.yml: envLLVM_VERSION21 -> 22, Windows ARM64$llvmVersion21.1.8 -> 22.1.8 (LLVM-22.1.8-woa64.exeexists upstream)build.yml/build-preview.yml/build-reusable.yml: stalellvm_versioninput default 19 -> 22build.ts,mac-release.bash:clang-21/clang++-21->clang-22/clang++-22Notes
compiler-rt-{darwin,windows}-22.1.8release tags are already published with sha256-pinned assets:LLVM 21's CodeView emittercomment on the disabledarm64-ltowindows-cross variant is left as-is; whether 22 fixed that register-mapping error hasn't been verified.Follow-up to #153. The corresponding Bun bump will land separately with
[build images].