The two commits before this were written against a main 903 commits older than
this one, so their comparison of clippy 1.98.0 against 1.99.1 was re-run over
every cargo root that has gained Rust code since. It found these.
Method, because the first attempt was wrong
`rustup run <toolchain> cargo clippy` does NOT select that toolchain's clippy.
`cargo` resolves the `clippy` subcommand by searching PATH for `cargo-clippy`,
and on this machine Homebrew's (1.99.1) comes first, so both toolchains reported
`clippy 0.1.99` and the comparison was of one clippy against itself. The runs
behind this commit call each toolchain's own binary by path
(`~/.rustup/toolchains/<tc>/bin/cargo-clippy`, with `RUSTC` set to match and
`RUSTUP_TOOLCHAIN` unset), which gives `clippy 0.1.98` and `clippy 0.1.99`.
Confirming the delta that way: of the 24 constants `std::f64::consts` has
carried, 1.98.0 flags 18 and 1.99.1 flags 20 — the two added are exactly
EULER_GAMMA and GOLDEN_RATIO, as the previous commit says.
What changed
- wai-quantum, engine/synth/kak.rs: `1.618_033_988_749_895` becomes
`std::f64::consts::GOLDEN_RATIO`. This is a `clippy::approx_constant`, which
is deny-by-default, so it is an error and not a warning. The line arrived on
2026-10-27, two days after the comparison was made, as one of six "mixing
weights with nothing in common" that `kak` tries in turn. The literal and the
constant are the same f64 — both `0x3ff9e3779b97f4a8` — so no value the
decomposition computes changes. The constant is stable well below this tree's
1.97 MSRV (it compiles on 1.96.0). The other five weights are not flagged:
1/sqrt(3) and Feigenbaum's delta are not constants clippy knows.
No workflow runs clippy inside wai/wai-quantum, so this was latent in CI and
would have met anyone who ran clippy there by hand.
- Six `assert!(x.is_empty())` the previous commit missed, five of which were
already in the tree when it was written: aac-core (translations, prediction
twice, symbols), access-core (scan_order) and openpay's op-connect (account).
`clippy::assert_is_empty` is new in 1.99, is allow-by-default, and reaches
these crates through their own `#![warn(clippy::pedantic)]`, which
`#![deny(warnings)]` then makes an error in the two aac crates.
Each gains a message naming the value instead of the array comparison the
previous commit used, because none of these six is a Vec or a slice: four are
a HashMap, a BTreeSet or `OrderDiff`, which cannot be compared to `[] as [T; 0]`
at all, and `Vec<PredictionCandidate>` derives Debug but not PartialEq, which
`assert_eq!` against an empty array needs. A message is what the lint asks for
anyway — it exists so a failure prints the value rather than only "false" — and
it is the reason the lint does not fire at the other 147 `assert!(…is_empty())`
sites that have arrived since: with a message supplied, it stays quiet.
Not changed, with the reason
- The 1.97 MSRV. `rust-version` is the floor a consumer of these reference
implementations must meet, not the compiler this tree builds with; raising it
narrows who can build an open standard and buys nothing, since no code here
needs 1.98 or 1.99. `wai-quantum-webgpu.yml` installs 1.97.0 beside 1.99.1 to
hold that floor, and that leg is untouched.
Co-Authored-By: Claude Opus 5 <[email protected]>
2ee9bfe7ad