reg_field.h/reg_flow.h fail to compile: Impl:: static-qualified calls against kernels' now-instance-method regulariser API

[balbasty]

Summary

fastfields-cpu-impl/reg_field.h and reg_flow.h fail to compile against current fastfields-kernels main. This blocks make -C fastfields-cpu-lib test entirely for the regulariser modules — i.e. it blocks CI/local verification for every open PR touching field_*/flow_* regularisers, including the just-merged-pending fastfields-kernels#52 (OOB wget fix) and the whole in-place-accumulate PR series (fastfields-cpu-lib#50, fastfields-lib#47, etc.).

Root cause

fastfields-kernels' regularisers (regularisers/field/{1d,2d,3d}.h, regularisers/flow/{1d,2d,3d}.h) were refactored to support runtime (bound::type::Dynamic) boundary conditions: every method that touches a boundary (which is effectively all of them — get_kernelsize_*, make_kernel_*, make_fullkernel_*, matvec_*, diag_*, kernel_*, relax_*) now holds bound::dyn<B> state per axis (see fastfields-kernels/CLAUDE.md: "Kernels that use dyn take a runtime bound::BoundVec and have non-static methods"). Confirmed directly — e.g. regularisers/field/2d.h:

CUDEV inline offset_t
get_kernelsize_bending(offset_t nc = C) // no `static`
{ return 6 * (C < 0 ? nc : C); }

fastfields-cpu-impl/reg_field.h never updated its call sites — every one is still the old static-qualified form:

using Impl = RegField<0, ndim, scalar_t, reduce_t, offset_t, BOUND...>;
...
reduce_t * kernel = new reduce_t[Impl::get_kernelsize_membrane(nc)]; // no instance
Impl::make_kernel_membrane(kernel, absolute, membrane, voxel_size, nc);
...
Impl::template matvec_membrane<op_apply<op, scalar_t, reduce_t> >(...);

grep -c "Impl::" across the two files: ~150 call sites (68 Impl::template …, plus get_kernelsize_*/make_kernel_*/make_fullkernel_*/kernelsize_* — the full surface of both files).

Why this wasn't caught earlier

fastfields-cpu-lib's dispatch layer was recently updated to thread a const bound::BoundVec & bvec argument through to every impl call (see the note in fastfields-cpu-lib#52's description: "main's dispatch functions now thread a const bound::BoundVec & bvec first argument through to every impl call"), which is the cpu-lib-side half of adapting to the kernels Dynamic-bound refactor — but the cpu-impl side (constructing an Impl instance from that bvec and calling instance methods on it) was never done. Confirmed via git worktree comparison against a completely unmodified fastfields-kernels main that this is not a regression from any specific recent PR — it's the missing other half of the kernels#42 (bound::type::Dynamic) adaptation.

Fix

Every Impl::-qualified call in reg_field.h/reg_flow.h needs to go through a constructed Impl instance instead of a static qualifier:

• For statically-instantiated (non-Dynamic) BOUND... packs, bound::dyn<B> is stateless/zero-cost, so a default-constructed (or bvec-passed-through-and-ignored) instance is correct and free.
• For Dynamic axes, the instance must be constructed from the runtime bvec cpu-lib's dispatch layer already threads down — this needs a real bvec-accepting constructor call, not a default one.

Recommend checking how other already-adapted cpu-impl modules (or cuda-impl, if it's ahead here) construct their Impl/Kernels<Config<...>> instance from a bvec, and mirroring that pattern mechanically across all ~150 sites in both files.

Verification

make -C ../fastfields-cpu-lib test CXX=clang++ must go from a compile error (call to non-static member function without an object argument) to green, with the existing test_reg_field/test_reg_flow check counts unchanged (this is a pure compile-compatibility fix, not a behaviour change).

Workstream: claude-jitfields-to-fastfields

[balbasty]

This is already fixed on main — no code change is needed.

The exact fix described here landed in #37 (b77d489, "reg_field/reg_flow: thread the runtime boundary condition through the loops"), merged 2026-07-29, two days before this issue was filed. On main today:

• reg_field.h: grep -c "Impl::" → 0
• reg_flow.h: grep -c "Impl::" → 25, and all 25 are Impl::kernelsize_* — static const offset_t data members used as array bounds. Those are correctly still static-qualified; they don't depend on the boundary condition.

The pattern #37 used is exactly the one recommended above: a leading const bound::BoundVec & bnd parameter, one Impl impl(bnd); per function, then instance calls (impl.get_kernelsize_absolute(nc), impl.template matvec_absolute<...>(...)). Making bnd the leading parameter means any un-updated call site is a hard compile error rather than a silently-wrong default.

Why the failure is still being observed

The dev tree resolves kernels/impl through symlinks to sibling working trees, so what gets compiled is whatever those trees have checked out, not the pinned submodule. fastfields-cpu-impl's working tree is currently on claude/jitfields-fastfields-migration-v5r416 (head efcb2d3), which branched before #37 and so still has the pre-bnd signatures. Building fastfields-cpu-lib main (which does thread bnd) against that stale checkout gives:

reg_field.cpp:88:9: error: no matching function for call to 'matvec_bending'
./impl/reg_field.h:403:6: note: candidate function template not viable:
 requires 10 arguments, but 11 were provided

i.e. an arity mismatch rather than the "call to non-static member function without an object argument" quoted in the report — cpu-lib now passes bnd, so overload resolution fails before the static-call diagnostic can fire. Same root cause, same stale checkout.

Verification on clean main

Assembled a fresh tree from the real pins — fastfields-cpu-lib@6aaa159 + fastfields-cpu-impl@b6eae48 (its pinned impl) + fastfields-kernels@15295c2 (its pinned kernels) — and ran make -j4 test CXX=clang++. Compiles clean, all 12 suites pass:

suite	checks	failures
test_distance	2352	0
test_distance_mesh	4622	0
test_distance_spline	704	0
test_posdef	4012	0
test_pushpull	308	0
test_pushpull_backward	6381	0
test_reg_field	4610	0
test_reg_flow	5859	0
test_reg_op	186	0
test_resize	630	0
test_restrict	65	0
test_splinc	4577	0

Suggest closing this as already-fixed by #37. Anyone hitting the compile error locally should update the sibling working trees (fastfields-cpu-impl, fastfields-cpu-lib, fastfields-kernels) to their respective mains rather than patching reg_field.h/reg_flow.h — re-applying the fix on top of the stale branch would conflict with #37 on merge.

Workstream: claude-jitfields-to-fastfields

---

Generated by Claude Code