Mutation gate has an architectural blind spot: mutants in cfg-gated code are vacuously MISSED on the runner's arch

[RyanCodrai]

.github/workflows/mutants.yml runs on ubuntu-latest (x86_64). cargo-mutants mutates source text, so a mutation inside a #[cfg(target_arch = "aarch64")] item still compiles there — the item is simply not built — no test can fail, and the mutant is reported MISSED. The gate then fails the PR for weak tests that are not weak.

Observed on PR #419, which touched the aarch64 None branch as part of #410:

MISSED   turbovec/src/encode.rs:935:5:  replace fused_quantize_scale_pack -> f32 with 1.0
MISSED   turbovec/src/encode.rs:1032:40: replace + with * in fused_quantize_scale_pack
15 mutants tested in 15m: 2 missed, 13 caught

fused_quantize_scale_pack is declared #[cfg(target_arch = "aarch64")] (turbovec/src/encode.rs:920).

Proof the mutants are killable, just not there. I applied the :1032 mutation (let d = offset + k → offset * k) on an aarch64 host and ran the same target the gate runs:

cargo test --release -p turbovec --lib
test result: FAILED. 78 passed; 13 failed

Thirteen tests kill it. Reverted, 91 passed; 0 failed.

So the tests are fine and the gate's verdict is an artifact of where it runs. Any PR touching aarch64-only code — the NEON kernels, the aarch64 dispatch — will hit this.

Options, roughly in order of preference:

1. Run the gate on a matrix including an aarch64 runner (macos-14 is already used elsewhere in ci.yml), so cfg-gated code is actually compiled somewhere.
2. Have the gate detect mutants inside cfg-gated items that the runner's target excludes, and report them as unviable rather than missed. cargo-mutants has --in-place/--exclude machinery that could be pointed at this, though I have not checked whether it can express "cfg not active on this target".
3. Failing either, document the blind spot in the gate's own failure text so the next person is not sent hunting for a missing test — the current message says "Each MISSED line above is an edit to your change that no test kills", which is misleading in this case.

The escape hatch ([skip mutants] / the skip-mutants label) works but is blunt: it drops the whole leg, including the 13 mutants that were legitimately caught in that same run.

[github-actions]

Claude encountered an error after 1s —— View job

---

I'll analyze this and get back to you.

[RyanCodrai]

Set aside for a maintainer decision: this is CI gate policy (thresholds, coverage strategy, runner architecture), where the right answer depends on what you want the gate to guarantee and what runner cost is acceptable. Flagged during an automated issue-fixing pass on 2026-07-30.

[RyanCodrai]

/summary

[tq-bot]

This issue reports a flaw in one of the project's automated quality checks, not in the code itself. The check works by deliberately introducing small bugs ("mutants") into the code and confirming that the tests catch them — if a bug slips through unnoticed, the check fails the change on the grounds that the tests are too weak. The problem is that some of turbovec's code only exists for a particular kind of processor (Apple-style ARM chips), while the check runs on a different kind (standard Intel/AMD machines). Bugs planted in that ARM-only code never actually run on the machine doing the checking, so no test could possibly catch them — and the check wrongly concludes the tests are inadequate. The author proved the point by planting the same bug on an actual ARM machine, where thirteen tests immediately caught it.

Left alone, this means any change touching the ARM-specific code will be unfairly blocked, and the failure message will send people hunting for a missing test that isn't missing. The issue suggests three fixes, from best to least: also run the check on an ARM machine so that code genuinely gets exercised; teach the check to recognize and set aside bugs planted in code the current machine can't run; or at minimum reword the failure message so it doesn't mislead. There's an existing override to skip the check entirely, but it's too blunt — it throws away the useful results along with the false alarm. The maintainer has marked this as needing a human decision, since the right choice depends on what the check should guarantee and how much running extra machines is worth.