ec45aaaca9
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]>
4 lines
122 B
TOML
4 lines
122 B
TOML
[toolchain]
|
|
channel = "1.99.1"
|
|
components = ["rustc", "cargo", "rust-std", "rustfmt", "clippy"]
|
|
profile = "default"
|