You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move the CI workflows from ubuntu-22.04 to ubuntu-24.04, and bump the pinned clang tooling (clang-format / clang-tidy, and the LLVM used by the CodeQL / fuzz builds) to the LLVM 18 that the 24.04 runner ships natively. The goal is reliability: several workflows currently depend on an externally-downloaded LLVM tarball plus a hard-coded libtinfo5.deb URL, and that combination is brittle.
Why (this is already biting)
.github/scripts/codeql_buildscript.sh downloads the clang+llvm-18.1.8-...-ubuntu-18.04 release tarball and then installs libtinfo5 from a hard-coded security-pocket URL (libtinfo5_6.3-2ubuntu0.1_amd64.deb). That exact file has rotated out of the pool (the runner's ncurses is now 6.3-2ubuntu0.2), so the wget 404s, libtinfo5 is missing, and linking wamrc against the tarball's libomptarget.rtl.amdgpu fails with undefined NCURSES_TINFO_5 symbols. Net effect: the nightly CodeQL Analyze job cannot finish today. (Fixed defensively in Fix the currently-failing CodeQL workflow and run it on pull requests #4980, but the root cause is the ubuntu-18.04 tarball needing a libtinfo5 that modern runners don't ship.)
ci/coding_guidelines_check.py pins clang-format-14 / git-clang-format-14, and the new clang-tidy gate (Run clang-tidy 21 on pull-request changed lines #4982) pins clang-tidy-14 to match — a version that is now two years behind and not the runner default.
What ubuntu-24.04 gives us
The ubuntu-24.04 runner image ships, preinstalled:
So LLVM 18 (clang-18, clang-format-18, clang-tidy-18) is available with no download and no libtinfo5 compat package (24.04 doesn't ship libtinfo5, and the native LLVM 18 doesn't need it). That removes three fragile moving parts at once: the tarball fetch, the libtinfo5.deb pin, and the version drift.
Proposal
Move the workflows to runs-on: ubuntu-24.04.
For the CodeQL and fuzz builds, use the runner-native LLVM 18 (/usr/lib/llvm-18) instead of the downloaded 18.1.8 tarball — deleting the libtinfo5 step entirely.
Bump clang-format / git-clang-format (and the clang-tidy gate) from 14 to 18, and update the ci/pre_commit_hook_sample + .clang-format version note to match.
Could be staged: (1) runner bump + native LLVM for CodeQL/fuzz first (this is the reliability win and removes the tarball/libtinfo5 fragility), then (2) the clang-format/clang-tidy14 → 18 bump as a follow-up.
Things to validate / costs
clang-format-18 reformat delta — the main friction: 18 formats some constructs differently than 14, so the 14 → 18 bump needs a one-time repo-wide reformat (or an accepted-deltas review). Worth doing as its own PR.
wamrc link against native LLVM — confirm llvm-18-dev (18.1.3) satisfies the REQUIRED_LLVM_LIBS the CodeQL/fuzz builds link; this is a patch-level difference from the pinned 18.1.8. (WAMR's own AOT/JIT LLVM handling via build_llvm.py is unaffected — this is only about the CI analysis builds.)
GCC default moves from 11 (22.04) to 13 (24.04); re-check the -Werror matrices.
Happy to prepare the PRs for whichever staging the maintainers prefer.
Suggested merge order & PR stack
Since filing, the concrete PRs are below. One update to the proposal: the version settled on clang 21, not 18 — it matches the LLVM shipped in Xcode 26/27, so contributors who build or auto-format on macOS get the same result as CI and as everyone on other LLVM-built platforms. It installs as a small (~50 MB) apt.llvm.org package (just the tool), not the multi-GB LLVM tarball this issue set out to remove.
To be explicit: this stack is a tooling-version alignment effort for easier ongoing maintenance and contribution — it is not an attempt to express a code-style preference in any way. The only goal is that every contributor's local clang-format / clang-tidy produces the same result as CI and as each other, so nobody is surprised by formatting or lint differences between platforms (e.g. Xcode's LLVM vs a Linux distro's).
clang-tidy 21 on ubuntu-24.04 + curated .clang-tidy
Diff-scoped gate; disables only noisy checks (misc-include-cleaner, …), keeps the bug-catchers (bugprone-narrowing-conversions, …). Best after #4992 so the tree is already 21-formatted
3
per-subsystem cleanup PRs
fix the residual clang-tidy diagnostics, one core/iwasm/* or core/shared subsystem per PR
Summary
Move the CI workflows from
ubuntu-22.04toubuntu-24.04, and bump the pinned clang tooling (clang-format/clang-tidy, and the LLVM used by the CodeQL / fuzz builds) to the LLVM 18 that the 24.04 runner ships natively. The goal is reliability: several workflows currently depend on an externally-downloaded LLVM tarball plus a hard-codedlibtinfo5.debURL, and that combination is brittle.Why (this is already biting)
.github/scripts/codeql_buildscript.shdownloads theclang+llvm-18.1.8-...-ubuntu-18.04release tarball and then installslibtinfo5from a hard-coded security-pocket URL (libtinfo5_6.3-2ubuntu0.1_amd64.deb). That exact file has rotated out of the pool (the runner's ncurses is now6.3-2ubuntu0.2), so thewget404s,libtinfo5is missing, and linkingwamrcagainst the tarball'slibomptarget.rtl.amdgpufails with undefinedNCURSES_TINFO_5symbols. Net effect: the nightly CodeQLAnalyzejob cannot finish today. (Fixed defensively in Fix the currently-failing CodeQL workflow and run it on pull requests #4980, but the root cause is the ubuntu-18.04 tarball needing alibtinfo5that modern runners don't ship.)libtinfo5-URL pattern was independently flagged on the new fuzz-smoke workflow (Smoke-test the libFuzzer harness on pull requests #4981), which reuses the same LLVM 18.1.8 tarball.ci/coding_guidelines_check.pypinsclang-format-14/git-clang-format-14, and the new clang-tidy gate (Run clang-tidy 21 on pull-request changed lines #4982) pinsclang-tidy-14to match — a version that is now two years behind and not the runner default.What ubuntu-24.04 gives us
The
ubuntu-24.04runner image ships, preinstalled:clang-format/clang-tidyat 16/17/18)So LLVM 18 (
clang-18,clang-format-18,clang-tidy-18) is available with no download and nolibtinfo5compat package (24.04 doesn't shiplibtinfo5, and the native LLVM 18 doesn't need it). That removes three fragile moving parts at once: the tarball fetch, thelibtinfo5.debpin, and the version drift.Proposal
runs-on: ubuntu-24.04./usr/lib/llvm-18) instead of the downloaded18.1.8tarball — deleting thelibtinfo5step entirely.clang-format/git-clang-format(and the clang-tidy gate) from14to18, and update theci/pre_commit_hook_sample+.clang-formatversion note to match.Could be staged: (1) runner bump + native LLVM for CodeQL/fuzz first (this is the reliability win and removes the tarball/
libtinfo5fragility), then (2) theclang-format/clang-tidy14 → 18bump as a follow-up.Things to validate / costs
clang-format-18reformat delta — the main friction: 18 formats some constructs differently than 14, so the 14 → 18 bump needs a one-time repo-wide reformat (or an accepted-deltas review). Worth doing as its own PR.clang-tidy-18check set — a few checks are added/renamed vs 14; the diff-scoped gate (Run clang-tidy 21 on pull-request changed lines #4982) keeps this low-noise, but a quick.clang-tidyreview is warranted.wamrclink against native LLVM — confirmllvm-18-dev(18.1.3) satisfies theREQUIRED_LLVM_LIBSthe CodeQL/fuzz builds link; this is a patch-level difference from the pinned 18.1.8. (WAMR's own AOT/JIT LLVM handling viabuild_llvm.pyis unaffected — this is only about the CI analysis builds.)-Werrormatrices.Happy to prepare the PRs for whichever staging the maintainers prefer.
Suggested merge order & PR stack
Since filing, the concrete PRs are below. One update to the proposal: the version settled on clang 21, not 18 — it matches the LLVM shipped in Xcode 26/27, so contributors who build or auto-format on macOS get the same result as CI and as everyone on other LLVM-built platforms. It installs as a small (~50 MB)
apt.llvm.orgpackage (just the tool), not the multi-GB LLVM tarball this issue set out to remove.To be explicit: this stack is a tooling-version alignment effort for easier ongoing maintenance and contribution — it is not an attempt to express a code-style preference in any way. The only goal is that every contributor's local
clang-format/clang-tidyproduces the same result as CI and as each other, so nobody is surprised by formatting or lint differences between platforms (e.g. Xcode's LLVM vs a Linux distro's)..clang-tidymisc-include-cleaner, …), keeps the bug-catchers (bugprone-narrowing-conversions, …). Best after #4992 so the tree is already 21-formattedcore/iwasm/*orcore/sharedsubsystem per PRIndependent CI-reliability PRs from the same effort — no ordering dependency, mergeable any time: