Rust: one toolchain, the latest stable #606
Loading…
Reference in a new issue
No description provided.
Delete branch "chore/rust-latest-stable"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The policy is one toolchain: the latest stable Rust, pinned at the repository root, with no floor beneath it and no second toolchain anywhere in CI.
Two open pull requests each did half of that and neither did all of it, so this replaces both. They were not duplicates — they overlapped in exactly one file:
rust-versionout of 476Cargo.tomlfiles, plus the docs that promised it) but left the pin at 1.98.0.Merging either alone leaves the repository in a state the policy forbids: #601 alone tracks a stale stable, #594 alone still installs a 1.97.0 toolchain beside the pin to check a floor that is not supposed to exist.
The one conflict, and how the policy settles it
Both touched
.github/workflows/wai-quantum-webgpu.yml. #601 deletes theMSRV 1.97.0job and itscargo +1.97.0 checkstep; #594 keeps the job and bumps its version. There is no technical tiebreak — the directive decides it. One toolchain means the job goes, so this takes #601's structure with #594's version: the job and its install are deleted, and what remains installs 1.99.1 only.What lands
rust-toolchain.toml→channel = "1.99.1".rust-versionkey removed from 476 manifests. It was a cargo convenience that turns an old toolchain into a readable message; it was never a support promise, and leaving it in print made it look like one.What deliberately does not move
Thirteen
1.98.0strings stay exactly as they are, because they are not pins — they are dated records of what was measured, and rewriting them would falsify the measurement. For examplestandards-build.ymlsays the jouleclaw fp16 flag was "Verified on a native arm64 Linux container (rustc 1.98.0): without the flag, 12 errors; with it, 4457 tests pass." That observation was made under 1.98.0 and remains true of 1.98.0.Three kinds of version string look alike in a grep and must not be treated alike: a pin (moves), an MSRV floor (is removed, because it implies a second toolchain), and a provenance record (is left alone).
One
rust-versionkey also remains, atjoule-code/joule-code-rs/vendor/wtransport/Cargo.toml— a vendored third-party crate, correctly untouched.Verification
rust-toolchain.tomlis1.99.1; zero occurrences of1.97.0in any manifest or workflow; the only1.98.0left under.github/is the provenance comment above.rust-versionkey remains, and it is the vendored one.linux, confirming this rebase preserved #603 rather than reverting it.check-lockfiles(60 lockfiles, all current),check-workflow-concurrency(77 workflows, each grouped per ref),check-tests-in-ci,check-spec-refs(1966 citations across 17 standards, all resolve) andcheck-no-vanity-metricsall pass locally.check-public-namesneeds a forge secret, so CI runs that one.One commit from #594 is intentionally absent: it was byte-identical to the proof-gate fix in #599, which has already merged.
🤖 Generated with Claude Code
This repository had four different answers to "what Rust does this need": rust-toolchain.toml 1.98.0 (the pin CI actually installs) 59 Cargo.toml files 1.97 (rust-version) 1 Cargo.toml file 1.88 (rust-version) INGEST.md 1.95.0 ("CI enforces both") The floor was enforced in exactly one place -- `wai-quantum-webgpu.yml` ran `cargo +1.97.0 check` against one crate's one feature. So 59 manifests declared a minimum nothing verified, and the top-level document told readers a version that had not been the pin for some time, crediting CI with checking it. The policy is to track the latest stable. That makes a floor below the pin something this repository does not promise, so the unenforced check goes, and the documents stop claiming a version and an enforcement that were not there: - `wai-quantum-webgpu.yml`: the `MSRV 1.97.0` step, the second toolchain its install step existed to fetch, and `MSRV` in the job's name. - `INGEST.md`: states the pin at the root, that CI installs exactly it, and that there is no floor beneath it. - `openpay/README.md` and `openpay/docs/00-foundation.md`: both named 1.95 as the toolchain, and the README credited CI with enforcing an MSRV. A version written in a document is a claim like any other. Stating 1.95 while the pin is 1.98.0, and "CI enforces both" while one crate was checked, is worse than stating nothing -- it reads as verified. **Not done here, deliberately.** The 59 `rust-version = "1.97"` keys and the one `1.88` stay for now. Removing them is not the small change it looks like: most member crates inherit via `rust-version.workspace = true`, which fails to parse the moment the workspace key is gone, so it is a coordinated edit across hundreds of manifests rather than sixty. The key also has value independent of any promise, since it turns an old toolchain into a clear message instead of a compile error. What it must not do is state a floor nobody checks, so the options are to delete it everywhere or to move it with the pin -- a decision with consumer-facing consequences, which is its own change. Co-Authored-By: Claude Opus 5 <[email protected]>The repository tracks the latest stable Rust, pinned at the root. A `rust-version` key states a *floor* -- the oldest toolchain a crate supports -- which is a different promise, and one this repository does not make. It also said 1.97 while the pin was 1.98.0 and nothing verified it, so it was a claim in the wrong direction and unchecked in both. So it goes, everywhere: 59 rust-version = "1.97" (workspace and package declarations) 417 rust-version.workspace = true (members inheriting them) 476 files, 476 deletions, 0 insertions The 417 are why this is not the sixty-file change it looks like from a grep for the value. A member inheriting a key that no longer exists does not fall back to a default -- its manifest stops resolving. Removing the declarations without the inherits would have broken every workspace that has members. Deliberately untouched: `joule-code-rs/vendor/wtransport/Cargo.toml`. That is a vendored third-party crate declaring a floor about itself, not about us, and our pin is above it. Editing vendored source to satisfy our own policy would make the copy diverge from upstream for no benefit. Verified rather than assumed: - all 493 `Cargo.toml` files in the tree parse (`tomllib`) - `cargo metadata --no-deps --locked` resolves on `joule-code-rs`, `wai-rs`, `openpay`, `mesh-rs`, `sandbox-rs` and `jcp-rs` -- the check that actually exercises workspace inheritance, which a TOML parse does not - no `Cargo.lock` changed; `rust-version` is not lockfile state `wai/wai-verify/Cargo.toml` already carried a comment saying it omits `rust-version` on purpose, so this makes the rest of the tree agree with the one crate that had already decided. What this gives up, stated plainly: cargo can no longer greet an older toolchain with "requires rustc 1.97" and will instead fail wherever the code first needs something newer. That is the cost of not maintaining a floor, and it is the right cost when the floor was fiction. Co-Authored-By: Claude Opus 5 <[email protected]>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]>