Repository navigation
Update to clang 21 #4509
Description
Activity
I don't think anything in the Jenkins CI is on clang 21, other than maybe
fedora-latest(although testing on that is currently suspended pending resolution of the DigitalOcean situation) andrhel10. Would have to check if we'd need to be on Ubuntu 26.04 (which we currently are not running) instead of 24.04 for clang 21.We generally avoid compiling our own version of e.g. clang or install a version on a Linux distro outside of the distro's package manager because it does not replicate what we'd be expecting contributors/downstream builders to be doing.
FWIW I kicked off a node-test-commit job for nodejs/node#66495 and as expected the results are not good (the only ones that passed were the alpine builds). Most of the Jenkins connected infra is running clang 19 or 20.
clang 21 is not available on:
- Ubuntu 24.04 from the official repositories and would require Ubuntu 26.04. That would be complicated by the only one of our providers offering Ubuntu 26.04 being DigitalOcean, for which we are waiting for a resolution to Solidify Digital Ocean Partnership #4499.
- Debian 12. It's only available on Debian 13 from the trixie-backports repository. Like Ubuntu 26.04, the only one of our providers offering Debian 13 is DigitalOcean.
clang-21 available with complications:
- RHEL 8 and 9 and 10. clang-21 is available, in fact we're deliberately pinning clang back to 20 on these machines. Unfortunately we cannot install multiple versions of clang via dnf from the official repositories, and clang is tied to llvm which affects rust (i.e. updating to clang 21 also moves to a later rust version). Options are:
- Move RHEL 9 and 10 to clang 21 and keep RHEL 8 on clang 20 and stop testing Node.js 27 on RHEL 8. We've only just moved building the official binaries for Node.js 27 to from RHEL 8 to RHEL 9 to align end-of-support dates,
- Move all of the RHELs to clang 21. This would also affect Node.js 24 and 22.
available (untested):
- AIX
Unknown availability:
- macOS
- smartos (I think that is still using gcc. Unknown if that can still build the simdjson update yet as job is still in queue).
- Windows
Suboptimal options:
- Provision the older distros, e.g. Ubuntu 24.04 and Debian 12, and then manually upgrade each to e.g. Ubuntu 26.04 and Debian 13. This requires manual set up and causes discrepancies between the actual OS on the machine and what is shown in the provider UIs. It means replacing/reprovisioning these if any of them run into trouble is going to be more complicated.
- Move more testing into containers. There is a slight risk in kernel mismatching (containers run with the kernel from the host machine) and we've previously seen issues with e.g. io_uring being highly sensitive to kernel version (although IIRC that's not enabled by default in Node.js anymore).
simdjson is maintained by collaborators. Isn't it an option to adapt it?
I'm not necessarily going to recommend updating to 22 on all platforms but I will merely for historic reference that the V8 15.5 update included a change which breaks the build on the (unofficial) RISC-V architecture because of some of the values in the header files. Fortunately I don't think any other platforms were affected.
Reacted by Levi Zimnodejs/node#66495 has been superseded by nodejs/node#66620, so maybe the immediate reason to update is no longer there?
IMO there are still incentives to bump the version we use regardless of simdjson status, it doesn't seem unlikely a similar issue would arise during Node.js 27 lifetime. But indeed, there's no rush, and if it can't happen on time, it's likely not a big deal
@aduh95 @richardlau This was a bug on simdjson's part, which was fixed by a patch release.
(Updating might be a good idea anyhow.).
Refs: nodejs/node#66541