Rust 1.99.1: the pin, every workflow that names a toolchain, and the clippy delta #575
2026-11-02
clippy 1.99: two findings the comparison missed, and one it could not have seen
Some checks failed
wai-quantum service / service · linux (pull_request) Successful in 4m55s
wai-quantum CPU vector units / member · vector unit, sve 128-bit (aarch64, emulated) (pull_request) Successful in 33s
wai-quantum CPU vector units / member · vector unit, rvv 128-bit (riscv64, emulated) (pull_request) Successful in 25s
wai-quantum CPU vector units / member · vector unit, sve 2048-bit (aarch64, emulated) (pull_request) Successful in 12s
wai-quantum CPU vector units / member · vector unit, avx2 (x86_64 silicon) (pull_request) Successful in 23s
wai-quantum CPU vector units / member · vector unit, sve 512-bit (aarch64, emulated) (pull_request) Successful in 24s
standards workspaces build + test / joulecontract-rs (joulecontract/joulecontract-rs, joulecontract-rs, linux-arm64, true) (pull_request) Successful in 2m22s
wai-quantum studio and desktop / desktop app · macos (pull_request) Successful in 3m2s
standards workspaces build + test / map-rs (map-conformance, map/map-rs, map-rs, linux-arm64) (pull_request) Successful in 2m37s
wai-quantum studio and desktop / desktop app · linux (pull_request) Successful in 5m40s
wai-quantum verdicts and repairs / the intent set and the verdict under wasm32-wasip2 (wasmtime) (pull_request) Successful in 1m15s
wai-quantum verdicts and repairs / verdicts, repairs and the intent set · linux (pull_request) Successful in 1m47s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 1m54s
WAI examples / WAI examples · portable · linux (pull_request) Successful in 8m50s
WAI examples / WAI examples · the archive, the readiness check, the browser and Apple · macos (pull_request) Failing after 15m29s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 9m21s
standards workspaces build + test / openpay (openpay, openpay, linux-arm64) (pull_request) Successful in 5m49s
WAI conformance / v2 vocabulary · manifests validate as stated (pull_request) Successful in 1m2s
WAI energy receipts / energy receipts · linux (pull_request) Successful in 13m52s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 24m24s
WAI conformance / cargo-class corpora · linux (pull_request) Successful in 19m29s
WAI conformance / each feature of the independent verifiers' steps compiles alone (pull_request) Successful in 13m15s
WAI conformance / delivery telemetry · CMCD and CMSD against an independent library (pull_request) Successful in 17s
WAI conformance / cross-arch byte-equality · linux-arm64 (pull_request) Successful in 35s
WAI conformance / cargo-class corpora · linux-arm64 (pull_request) Successful in 19m49s
WAI conformance / C2PA manifest emission · signed, read back, validated (pull_request) Successful in 2m14s
WAI examples / WAI examples · android-app · linux-arm64 (pull_request) Successful in 7m11s
wai-quantum npu-cores member / member · npu-cores absent (linux-arm64) (pull_request) Successful in 59s
WAI energy receipts / energy receipts · linux-arm64 (pull_request) Successful in 16m18s
WAI conformance / independent verifiers · claims, JWP, key discovery and integer payloads (Python) (pull_request) Successful in 1h18m57s
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]>
toolchain: Rust 1.98.0 -> 1.99.1 (change-controlled pin)
Approved by the owner on 2026-10-22. Procedure: change `channel`, run `rustup show`, then run the pipeline. What changed - rust-toolchain.toml and eoc/eoc-rs/rust-toolchain.toml: channel "1.98.0" becomes "1.99.1". These are the only two pins in the tree, and the root one governs every other cargo root. - 64 workflows under .github/workflows (the forge's CI): every `Install Rust 1.98.0`, `rustup toolchain install / default / component add / target add --toolchain 1.98.0` and `--default-toolchain 1.98.0` now names 1.99.1 (409 lines). Two of those lines are in build steps rather than install steps (wai-conformance.yml's two `wasm32 (unix)` steps each `rustup target add --toolchain`), and they move with the rest: a target added to a toolchain that is not installed is an error. - Left as they are, because they record what was measured on 1.98.0: standards-build.yml's "Verified on a native arm64 Linux container (rustc 1.98.0)", wai-conformance.yml's note on Rust 1.98's LLD 22, and the "rustc 1.98.0 (example)" strings in receipts, vectors and docs. The one-codegen-unit workaround that note explains also stays. 1.99.1 ships LLD 23.1.1, which the note says links those inputs, but removing the workaround should wait for a run at the CI path on x86_64. Why - 1.98.0 has a P-critical miscompile, rust-lang/rust#161441 (I-miscompile, regression-from-stable-to-stable). rustc emits a vacant (null) method slot in a trait-object vtable, so a safe dynamic call jumps to address zero (undefined behaviour). RELEASES.md records the fix in 1.98.1 ("rustc: fix miscompilation in generating vtables"). - 1.99.1 is the current stable (channel manifest dated 2026-10-15; rustc 58cf8f9c3 2026-10-13). It also fixes 1.99.0's own regressions: wcslen on UEFI and embedded targets, x86_64 FFI `bool` returns, and the rust-lld rpath on macOS. Evidence All of it ran on the build host ([email protected], aarch64-apple-darwin) through ~/kani-logs/remote/rb. Nothing was built on the dev Mac. - `rustup show`: the active toolchain is 1.99.1-aarch64-apple-darwin, "overridden by .../rust-toolchain.toml" (and by eoc/eoc-rs's own file there). rustc 1.99.1 (58cf8f9c3 2026-10-13), LLVM 23.1.1, clippy 0.1.99, rustfmt 1.10.0. The baseline is rustc 1.98.0 (88d9e12ae 2026-08-18). - Scope: every cargo root the pin governs, which is 46 of the 49 tracked lockfiles. The other three: two are vendored crates that resolve inside their parents, and wai/wai-rs/fuzz builds on its own pinned nightly. - Trees. The final tree is main at96117c570plus these two commits. Main moved four times while this ran, and each root's evidence comes from the newest tree it was run on: - 13 roots on the final tree: every root main changed after1a465f23d, and every root that consumes such a crate by path. - 12 roots on1a465f23dplus these two commits. - 7 roots onb16816671plus these two commits. - 14 roots onaa61ab3b9plus the pin change. For each root in the last three groups, checked with git diff and the lockfiles' path packages: none of its files, and no crate it reaches by path, differs on the final tree. - Each root got: (a) `cargo fmt --all -- --check` on the pin and on 1.98.0. The output is byte-identical in all 46. CI gates no root on rustfmt, and none is rustfmt-clean on main. (b) `cargo clippy --locked --keep-going --workspace --all-targets` on both toolchains, with the diagnostics compared line by line. After the previous commit, no root has a diagnostic that only 1.99.1 reports. openpay's one differing line is the same lint at the same site, reworded. (c) `cargo test --workspace --locked`. (d) the root's other CI steps that can run on this host: feature-gated tests, conformance suites, release-profile tests, the aac page-set checks, and every clippy -D warnings gate. The gates are standards-build's macOS meter and omni lints (jouleclaw-energy x2, jouleclaw-omni metal, jouleclaw-loader-gguf, jcp, proof, eoc, sandbox), wai-pack, wai-quantum-cli (default, no-default and metal), wai-quantum-service, wai-quantum-qpu and wai-quantum-desktop. - Totals: `cargo test --workspace` ran in 43 roots: 12,532 passed, 1 failed, 101 ignored. The other 3 roots are wasm32-only, and their `cargo build --release --target wasm32-unknown-unknown` passed. Every other CI step passed (62 of 62). - On the final tree: scripts/check-lockfiles.sh (cargo 1.99.1) found all 47 lockfiles current, and scripts/check-advisories.py passes. - tokio is 1.54.1 in every lockfile cargo reads. That is patched for both RUSTSEC-2026-0386 (>= 1.53.3) and RUSTSEC-2026-0384 (>= 1.54.1). The 1.53.1 in vendor/wtransport/Cargo.lock is the upstream file kept with the vendored source; cargo resolves wtransport inside its parents, and both gates skip that file. - What is not green, each one reproduced on 1.98.0: - wai-ops-gpu: under the debug profile, `corpus` trips the debug_assert at exec.rs:187 on both toolchains. CI runs it in release only, and that passes (6/6). - wai-ops: clippy::derived_hash_with_manual_eq (deny-by-default) on both toolchains. No CI job runs clippy there. - wai-vector/wasm: `--all-targets` cannot build the lib-test target (its own `panic_impl`) on either toolchain. `clippy --lib` for wasm32 reports 0 diagnostics on both. - eoc-cascade's hit_calibration_process_energy test reads real energy counters, and it fails some of the time on the loaded shared host. In interleaved runs each toolchain passed 18 of 20. The full eoc-rs suite passed on the final tree (741 passed). - Environment, not code: - wai-quantum-desktop embeds the Studio's build, so wai/quantum-studio was built first (`npm ci`, `node build.mjs`), as CI does. - Not covered here: the x86_64 and arm64 Linux and Windows legs; the GPU, NPU, FPGA, emulator and hardware-meter legs; wasm32 tests under Node, wasmtime and wasip2; and the fuzz job. Co-Authored-By: Claude Opus 5.5 <[email protected]>
clippy 1.99: fix what Rust 1.99.1's clippy newly reports, before the pin moves
These are the only lints clippy 1.99.1 reports that clippy 1.98.0 does not.
Every cargo root in the tree was compared on both toolchains (the evidence is
in the next commit). 1.98.0's clippy also builds every target of the fixed
code, and reports nothing it did not report before, so this commit stands
under either pin.
What changed, and why
- clippy::assert_is_empty is new in 1.99. 36 sites, all in test code
(#[cfg(test)] modules; no lib or bin build reports any):
aac-core and access-core, 23 sites; openpay's op-crypto-extra, op-emv,
op-iso20022, op-reconciliation, op-routing, op-screening, op-settlement
and op-tax, 13 sites. `assert!(x.is_empty())` becomes
`assert_eq!(x, [] as [T; 0])`, `assert_ne!` for the negation, or `""` for
strings, so a failure prints the value instead of only "false". aac-core and
access-core are `#![deny(warnings)]` and `#![deny(clippy::all)]`, so without
this their clippy run fails on 1.99.1.
Judgment call: at 18 of the 36 sites, clippy's own "MachineApplicable"
suggestion does not compile. It names local types by crate-relative path
(`finder::Found`, which is not in scope in a test module), or offers a bare
`[]` whose element type cannot be inferred. So each site names its element
type as its own module sees it (`[] as [Found; 0]`, `[] as [f64; 0]`). The
four lines rustfmt would wrap are wrapped the way rustfmt wraps them.
- clippy::approx_constant (deny-by-default) now knows EULER_GAMMA and
GOLDEN_RATIO. Both are in std::f{32,64}::consts and stable since 1.94; the
jouleclaw workspace MSRV is 1.97.
- jouleclaw-omni, inference/architecture/mochi.rs: `1.618_034` becomes
`std::f32::consts::GOLDEN_RATIO`. They are the same f32
(1.61803400516510009765625), so the latents do not change. This file is
in standards-build.yml's macOS gate (`cargo clippy -p jouleclaw-omni
--features metal -- -D warnings`), which fails on 1.99.1 without the fix.
- jouleclaw-outlier, c_factor: `0.5772156649` becomes
`std::f64::consts::EULER_GAMMA`. Judgment call: the literal was
truncated, so c(n) moves by 3.1e-12. The normalisation in the
isolation-forest paper uses the Euler-Mascheroni constant itself, so this
is the intended value. No other crate and no committed vector reads these
scores, and the crate's tests pass unchanged.
- smart-byte-rs/Cargo.lock: async-trait 0.1.89 becomes 0.1.92, which adds
syn 3.0.9 as its dependency. 0.1.89 put `#[must_use]` on every trait method
it generates. clippy 1.99 now counts the returned `Pin<Box<dyn Future>>` as
must_use already, so clippy::double_must_use fired at 9 #[async_trait] trait
methods. The attribute there is the macro's, not ours, so the right fix is
the macro: 0.1.92 no longer emits it, and every other lockfile in this tree
already uses 0.1.92. A narrow `cargo update -p async-trait --precise 0.1.92`
also moved data-encoding-macro-internal (which accepts syn >=1, <3) from syn
2 to syn 1. That was put back to syn 2.0.117, as on main, so the lock
changes only what the bump needs. `cargo update --workspace --locked` and
scripts/check-lockfiles.sh accept it.
Left as they are
- openpay op-dispute-evidence evidence.rs:92 (clippy::double_must_use) is
reported on 1.98.0 too. Only the message's wording changed in 1.99.
Co-Authored-By: Claude Opus 5.5 <[email protected]>