ci: run coding-guidelines on ubuntu-24.04 with clang-format-21 + reformat

[matthargett]

Summary

Moves the coding-guidelines gate to ubuntu-24.04 and bumps its formatter from clang-format-14 to clang-format-21, then reformats the tree to match. The clang-format slice of #4983.

Why clang-format-21

clang-format 21 matches the LLVM version shipped in Xcode 26 and 27. Pinning it means contributors who build or auto-format WAMR on macOS/Xcode produce the same result as CI and as contributors on other LLVM-built platforms — so nobody gets version-specific formatting surprises when clang-format's defaults shift between releases. It installs as a small (~50 MB) apt package from apt.llvm.org (the wget fetches only the ~2 KB signing key; the tool comes via apt), not a multi-GB LLVM toolchain download that previously exhausted disk space on runner images.

What changed

• Commit 1 (config): coding_guidelines.yml runs on ubuntu-24.04 and installs clang-format-21 from apt.llvm.org; coding_guidelines_check.py and the pre-commit sample pin clang-format-21 / git-clang-format-21. .clang-format's version note is updated (and its clang-formt typo fixed).
• Commit 2 (reformat): mechanical clang-format-21 -i (21.1.8, matching the apt.llvm.org package) over the coding-guidelines-checked sources.

Noise: small

43 of 441 files (~230 lines) change — the code was already close to this style, and .clang-format needs no option changes. Standalone reformat commit for easy review.

Scope

Just clang-format. The clang-tidy bump to 21 + .clang-tidy curation is a separate follow-up: the wildcard config surfaces ~3,300 pre-existing diagnostics at 21 (dominated by misc-include-cleaner), so it needs re-tuning first — while keeping the bug-catching checks (e.g. bugprone-narrowing-conversions) enabled.

[lum1n0us]

My preference would be not to merge this change for now.

Ubuntu 22.04 provides clang-format-14 as a default package, which matches our current CI requirement. On Ubuntu 24.04, installing clang-format-21 requires the external apt.llvm.org repository instead of the distribution-provided clang-format-18, adding repository, trust, and maintenance overhead for contributors.

This change also introduces a large mechanical reformat, increases review noise and potential merge conflicts, and adds CI installation steps and execution time. More importantly, it has not demonstrated a project-specific formatting or correctness benefit over clang-format-14. Matching Xcode 26/27 may be useful for some contributors, but it does not currently justify changing the project-wide formatting baseline.

I would suggest keeping clang-format-14 for now and revisiting this when there is a concrete compatibility issue or a broader, well-defined toolchain migration plan.

@TianlongLiang @srberard

[matthargett]

Ubuntu 22.04 provides clang-format-14 as a default package, which matches our current CI requirement. On Ubuntu 24.04, installing clang-format-21 requires the external apt.llvm.org repository instead of the distribution-provided clang-format-18, adding repository, trust, and maintenance overhead for contributors.

To be clear, the project already installs from apt.llvm.org, which is why I thought it was okay to keep. That said, if reducing dependencies like that one is preferred, I can accommodate:)

This change also introduces a large mechanical reformat, increases review noise and potential merge conflicts, and adds CI installation steps and execution time. More importantly, it has not demonstrated a project-specific formatting or correctness benefit over clang-format-14. Matching Xcode 26/27 may be useful for some contributors, but it does not currently justify changing the project-wide formatting baseline.

It also helps get better alignment with Android NDK 28/29/30, but I understand your point of view. The goal was to ease maintenance/review overhead so contributions could have more axes of automatic verification before a human steps in. A couple of points from that perspective:

• clang-tidy 18 has bug-finding checks relevant to memory safety in a wasm runtime (suspicious-memory-comparison, signed-char-misuse, too-small-loop-variable) that 14 lacks. I think this is critical, and tidy 21 found issues in the e posting open PRs that I have in my integration branch. (I haven't tested if 18 finds the same ones yet.)

• clang-format 14 has known misformatting bugs with heavily macro’d code that are fixed in 18. if we haven't hit them yet, and are confident that we won't hit them and trigger an interrupt, then it's okay by me. I wasn't trying to express preference/opinion on style, just to try and lighten the workload on maintainers.

• ubuntu-24.04 ships clang-format-18 natively — zero external dependencies. in terms of Ubuntu 22, I think it makes sense to be proactive instead of having an interrupt happen when the EOL curtain comes down

I would suggest keeping clang-format-14 for now and revisiting this when there is a concrete compatibility issue or a broader, well-defined toolchain migration plan.

Ok. This was driven by the email discussion about the current overhead that contributes to longer review/merge times. If you can give me more specific direction on what can be accepted here, I can get help out.

In the meantime, I'll keep integrating features, fixes, and optimizations in my fork branch and deploying to my mobile/XR apps to prove things out :) I'm not blocked, but I try to avoid long-lived forks if I can help it since it fragments the ecosystem/community.