What
src/vt/op_provider.cpp's OpNameImpl is a deliberately exhaustive switch (OpId) with no default, so -Wall -Werror=switch fails the build when an OpId is appended without naming it. It was added by 0541cbeaa during the LTX-2.5 campaign and does not exist on main yet — it arrives when row/MODEL-DIFFUSION-LTX25 lands.
The guard works. Merging 192 commits of main into the campaign branch fired it immediately on five newly absorbed ops (kAttentionDenseFa2, kMatmulFp8CublasLtAlphaVec, kMamba2ChunkScan, kMamba2StateUpdate, kRmsNormGatedGroup).
Why it is a defect anyway
AGENTS.md § Records: "No surface that every PR must write. If N concurrent PRs all edit file F, then F is a lock."
Adding an OpId already forces an edit to include/vt/ops.h. OpNameImpl makes that two locked files instead of one, for a mapping that is pure data. Two concurrent kernel PRs now conflict in two places rather than one, and the second conflict carries no information the first does not.
AGENTS.md also names the fix shape: a record surface is admissible when it is "derived at read time, so nobody writes it."
Suggested fix
Single-source the enum and its names from one list in include/vt/ops.h (X-macro or equivalent), so the enum and OpName are both generated from it. One list to append to, one conflict site, and the exhaustiveness property is structural rather than enforced by a compiler flag on a second file.
Why not now
The change touches a core shared header and would conflict with every in-flight kernel branch, for no LTX-2.5 benefit. Recorded as owed rather than done in-flow; the guard is correct in the meantime, just more expensive than it needs to be.
Found while merging origin/main into row/MODEL-DIFFUSION-LTX25 (#435).
What
src/vt/op_provider.cpp'sOpNameImplis a deliberately exhaustiveswitch (OpId)with nodefault, so-Wall -Werror=switchfails the build when anOpIdis appended without naming it. It was added by0541cbeaaduring the LTX-2.5 campaign and does not exist onmainyet — it arrives whenrow/MODEL-DIFFUSION-LTX25lands.The guard works. Merging 192 commits of
maininto the campaign branch fired it immediately on five newly absorbed ops (kAttentionDenseFa2,kMatmulFp8CublasLtAlphaVec,kMamba2ChunkScan,kMamba2StateUpdate,kRmsNormGatedGroup).Why it is a defect anyway
AGENTS.md § Records: "No surface that every PR must write. If N concurrent PRs all edit file F, then F is a lock."
Adding an
OpIdalready forces an edit toinclude/vt/ops.h.OpNameImplmakes that two locked files instead of one, for a mapping that is pure data. Two concurrent kernel PRs now conflict in two places rather than one, and the second conflict carries no information the first does not.AGENTS.md also names the fix shape: a record surface is admissible when it is "derived at read time, so nobody writes it."
Suggested fix
Single-source the enum and its names from one list in
include/vt/ops.h(X-macro or equivalent), so the enum andOpNameare both generated from it. One list to append to, one conflict site, and the exhaustiveness property is structural rather than enforced by a compiler flag on a second file.Why not now
The change touches a core shared header and would conflict with every in-flight kernel branch, for no LTX-2.5 benefit. Recorded as owed rather than done in-flow; the guard is correct in the meantime, just more expensive than it needs to be.
Found while merging
origin/mainintorow/MODEL-DIFFUSION-LTX25(#435).