Feature-gated (cpal) code is never type-checked: the gate and pre-push hook both build --no-default-features

[dc0sk]

Found while fixing #1369, which edits run_drive — a shipped CLI subcommand behind
#[cfg(feature = "cpal-backend")].

The gap, measured rather than argued

Every routine check builds with --no-default-features, which switches cpal-backend off:

• scripts/gate.sh → cargo clippy --workspace --no-default-features --all-targets and
  cargo test --workspace --no-default-features
• .cargo-husky/hooks/pre-push:73,84 → the same two flags

So #[cfg(feature = "cpal-backend")] code is never type-checked by either.

Probe, run at 331ba2d5. A planted type error inside run_drive
(engine.this_method_does_not_exist(); — valid syntax, no such method):

GATE clippy --workspace --no-default-features --all-targets  -> rc=0   (invisible)
cargo check -p openpulse-cli --features cpal-backend         -> rc=101 (caught)
      error[E0599]: no method named `this_method_does_not_exist` found for struct `ModemEngine`

Scope it correctly — my first probe got this wrong. A syntax error IS caught (rc=101), because
#[cfg]-disabled code must still parse. What escapes is everything after parsing: type errors,
borrow errors, wrong arity, renamed methods. So the failure mode is not "garbage compiles" but
"the feature-gated path silently rots as the APIs under it change" — exactly the code most likely
to drift, since nobody compiles it while editing something else.

What is behind that gate

openpulse-cli's cpal-backend is on by default, so a developer running plain
cargo build -p openpulse-cli does compile it — which is why this has not bitten yet. It is the
automated checks that do not.

calibrate drive is the example at hand: it keys a real transmitter and is the operator's TX-drive
tuning tool. Its correctness matters more than most, and no automatic check compiles it.

CI does not close it either

ci.yml:324 has a Build cpal CLI step, but it is (a) inside jobs scoped to
startsWith(github.head_ref, 'release/') || workflow_dispatch (#1120/#1144), and (b) conditional on
steps.aloop.outputs.available == 'true' — snd-aloop being present on the runner, with a
::warning:: and a skip when it is not. So on a normal PR it never runs, and on a release it runs
only if the runner cooperates.

Options

1. Add one cargo check --features cpal-backend step to gate.sh. Cheap — a check, not a test
   run, and only the crates that have the feature. It would have caught the planted error. Note
   openpulse-audio, openpulse-ardop, openpulse-kiss and openpulse-testbench have their own
   cpal features with the same exposure, so the step should cover the set rather than the CLI alone.
2. Make the pre-push hook do the same for touched crates that carry a cpal feature.
3. Accept it, and record in CLAUDE.md that feature-gated paths are developer-compiled only — the
   honest version of the status quo.

Related: #1144 (the gate does not run at merge), #1120 (why ci.yml is release-scoped). Distinct
from both: this is code that no configuration of the local gate compiles.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[dc0sk]

Correcting my own filing: this repo already carries this exact rot guard for another feature, and I did not cite it. The issue that records "feature-gated code rots because nothing compiles it" was itself written without checking whether the guard existed — the same miss, one level up.

.github/workflows/ci.yml:197-206:

The per-plugin gpu feature is never compiled by the --no-default-features gates above, so its #[cfg(feature = "gpu")] paths rot silently (PR #424 found a build break + clippy + flaky-test issue only reachable here). This job compiles and lints the GPU paths on every change. It does NOT run the GPU tests — CI runners have no wgpu adapter, so those would only exercise the CPU fallback; compile + lint is the rot guard.

- name: GPU feature build gate
  run: cargo build --no-default-features --features gpu -p bpsk-plugin -p qpsk-plugin -p psk8-plugin -p qam64-plugin -p scfdma-plugin

So the mechanism, the reasoning, and even the "compile + lint, not test" scoping were all established here already — and PR #424 is the precedent showing the failure is real, not hypothetical: a build break, a clippy finding and a flaky test reachable only through the feature.

What that changes:

1. The fix has a template. Whatever lands for cpal should look like the GPU gate, not be invented: compile + lint the feature across the crates that carry it (openpulse-audio, -cli, -ardop, -kiss, openpulse-testbench), and deliberately NOT run the tests, since they need real audio hardware exactly as the GPU tests need an adapter.
2. The GPU guard does not close its own gap either. It sits inside the jobs scoped to startsWith(github.head_ref, 'release/') || workflow_dispatch (ci: run the full workspace gate only on release PRs #1120), so it does not run on a normal PR — the same limitation this issue found for cpal. Both features are unguarded per-PR.
3. That strengthens option 1 (a gate.sh step) over adding another CI job: the local gate is the only thing that runs on every change, and moving the gpu guard there alongside cpal would fix both. Worth doing as one change rather than two.

Nothing in the measured finding changes — the planted type error still gives gate clippy rc=0. What changes is that this is the second instance of a known class with a documented precedent, which makes it a stronger candidate for a standing gate step and a weaker candidate for "accept it" (option 3).

[dc0sk]

Moved to #1418 — this comment originally carried a full finding; it belongs in its own issue.

Summary of the relationship, so the distinction is not lost when this one closes: #1418 is the same
class as this issue (a build configuration no automated check compiles) with the opposite
mechanism. Here a feature is off in the gate and the gated code is never type-checked. There the
gate's own --all-targets silently switches the instruments feature on, so the ungated
configuration — the one the shipped binaries link — is never linted.

Consequence worth carrying into whatever PR closes this one: adding cargo check --features cpal-backend (option 1 above) does not close #1418, and the ci.yml GPU template cited earlier does
not transfer to it. #1418's fix is a pass with fewer targets, not more features.