Skip to content

build: bump abseil pin for Clang >= 21#5

Draft
krystophny wants to merge 6 commits into
mainfrom
build-clang21
Draft

build: bump abseil pin for Clang >= 21#5
krystophny wants to merge 6 commits into
mainfrom
build-clang21

Conversation

@krystophny

Copy link
Copy Markdown
Member

What

Bump the CMake FetchContent abseil pin from the 2024-08 commit to the
20260107.1 LTS tag.

Why

The differentiable VMEC++ work (Enzyme autodiff) requires Clang, since the
ClangEnzyme plugin only attaches to a Clang frontend. The 2024 abseil pin does
not compile under Clang >= 21:

  • absl/strings/ascii.cc uses absl::Nonnull, whose EnableNonnull SFINAE the
    Clang 21 frontend rejects.
  • absl/strings/numbers.cc then fails with nullability-annotated out-of-line
    definitions that no longer match their declarations.

20260107.1 compiles cleanly under both Clang 21.1.8 and GCC. This is the same
abseil release nixpkgs builds against its Clang 21 toolchain. The newest tag
(20260526.0) was rejected: it reintroduces the numbers.cc mismatch under
Clang 21, so this pin deliberately stops at 20260107.1.

This is the first patch in a stack that adds an Enzyme-based differentiable build
of VMEC++. It changes only the CMake dependency pin; no source changes.

The Bazel build keeps its own abseil version from the Bazel Central Registry and
is untouched.

Verification

All builds: CMAKE_BUILD_TYPE=Release, -DVMECPP_USE_FFTX=OFF, target
vmec_standalone.

Before, Clang 21.1.8, old pin:

absl/strings/ascii.cc:183:11: error: no member named 'Nonnull' in namespace 'absl'
absl/strings/numbers.cc:413:38: error: out-of-line definition of
    'RoundTripDoubleToBuffer' does not match any declaration in namespace
    'absl::numbers_internal'
ninja: build stopped: subcommand failed.

After, this pin:

Clang 21.1.8:  build=0 (0 errors)   [221/221] Linking CXX executable vmec_standalone
GCC 16.1.1:    EXIT=0 errors=0      [221/221] Linking CXX executable vmec_standalone

No numerical regression. vmec_standalone examples/data/solovev.json, final
multigrid step:

GCC (baseline):  MHD Energy = 2.548352e+00
Clang 21:        MHD Energy = 2.548352e+00

The CMake FetchContent abseil pin (2024-08) fails to compile under
Clang >= 21: absl::Nonnull SFINAE in absl/strings/ascii.cc and the
numbers.cc nullability annotations are rejected by the newer frontend.
Bump to the 20260107.1 LTS, which compiles cleanly under Clang 21.1.8
and GCC. Clang is the compiler required for the Enzyme autodiff build.

The Bazel build keeps its own (BCR) abseil pin and is unaffected.
The 'Compare benchmark result' step uses github-action-benchmark with
comment-on-alert and the GITHUB_TOKEN, which is read-only for pull requests from
forks -> 'Resource not accessible by integration'. Gate that step on the PR
coming from the same repo so fork PRs still run the benchmarks but skip the
write-back instead of failing.
The pinned vmec-0.0.6 cp310 wheel was f90wrapped against numpy 1.x. Under
the numpy 2.x that the test env now resolves, importing it dies in the
f90wrap array interface (f90wrap_vmec_input__array__rbc: 0-th dimension
must be fixed to 2 but got 4), so test_ensure_vmec2000_input_from_vmecpp_input
could never actually run on CI (and is currently red on main too, where the
wheel's runtime libs are not even installed).

Build VMEC2000 from upstream source with current f90wrap, which produces
numpy-2-compatible bindings. The recipe mirrors SIMSOPT's own CI
(hiddenSymmetries/VMEC2000, cmake/machines/ubuntu.json). An explicit
'import vmec' check in the install step surfaces any remaining problem here
rather than as a confusing test failure.
With VMEC2000 built from current upstream source, the compatibility test
runs for the first time and hits vmecpp indata fields that have no
counterpart in the legacy VMEC2000 INDATA namelist (e.g.
free_boundary_method), which raised AttributeError. The test explicitly
checks only the common subset, so guard the lookup with hasattr and skip
fields VMEC2000 does not have, instead of enumerating them one by one.
Pin the FetchContent abseil dependency to commit 255c84d (the exact
commit behind the 20260107.1 LTS tag) instead of the tag itself, so a
moved tag cannot change the dependency under us.
Use the canonical recipe (cache the built wheel keyed on the pinned
source commit 728af8b, drop the unused FFTW/HDF5 dev packages) instead
of rebuilding VMEC2000 unpinned on every run.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant