chore(ci): decouple MSRV from the development toolchain - #3180
Merged
Conversation
`rust-toolchain` pinned the MSRV, and CI recovered the MSRV by parsing `rustup show active-toolchain`. That coupling forced every contributor's toolchain to the MSRV, which is now old enough that current tooling refuses to work against it: rust-analyzer requires 1.94.0 or newer and misresolves std macros on older sysroots. Point `rust-toolchain` at stable and derive the MSRV in CI from the `rust-version` field that every crate already declares. The MSRV itself is unchanged at 1.92, and the test matrix still builds and tests against it explicitly. MSRV enforcement continues locally through clippy's `incompatible_msrv` lint, which is warn by default, denied in CI via `-D warnings`, and already configured by the `msrv` key in the `.clippy.toml` files. That covers use of library APIs stabilized after the MSRV, but not newer language features, so the MSRV matrix job remains the authority. Because nothing pins the MSRV in a single place anymore, the definitions step now fails if the crates stop agreeing on a `rust-version` rather than silently testing whichever version the parsed crate happened to declare. The nightly pin in tools/xdp/ebpf is left alone; it is a build requirement for the eBPF programs rather than an MSRV.
The previous check required every crate to declare an identical `rust-version`, which would reject a pattern this repository has relied on before: the xdp and wireshark workspaces both carried a higher minimum than the repository MSRV while their dependencies outpaced it, and they are the crates most likely to need that again. Check the actual invariant instead. The MSRV is the floor s2n-quic promises, so no crate may declare lower than it, while a crate requiring a higher version is fine.
With the MSRV no longer expressed by these files, they served no purpose. No CI job depended on them: every job that compiles Rust installs and overrides its own toolchain, and the ones that don't (env, compliance, copyright, kani, ci-status-report) never invoke rustc. Two places already worked around the files instead of relying on them: the cargo-deny job deleted the root file before running, and .dockerignore excludes it from the build context. Drop the now-failing `rm rust-toolchain` step from the cargo-deny job, since `rm` errors on a missing file, and document the development toolchain in CONTRIBUTING to replace the components the files installed. tools/xdp/ebpf/rust-toolchain.toml stays. That pin is a build requirement rather than an MSRV statement: the bpf targets are tier 3 with no prebuilt `rust-std`, so `core` has to be compiled from source with `-Zbuild-std`, which is still nightly only.
WesleyRosenblum
changed the title
WesleyRosenblum
marked this pull request as ready for review
July 31, 2026 23:16
Mark-Simulacrum
approved these changes
Aug 3, 2026
boquan-fang
approved these changes
Aug 3, 2026
This was referenced Aug 3, 2026
dougch
added a commit
to awslabs/duvet
that referenced
this pull request
Aug 5, 2026
* ci: remove rust-toolchain pin; derive MSRV from Cargo.toml The repo-root `rust-toolchain` file pinned the toolchain to 1.88.0. rust-analyzer requires 1.94.0 or newer and refuses to work against a 1.88 sysroot, producing "too old" pop-ups for any developer running a recent rust-analyzer build. The MSRV is already correctly declared via `rust-version = "1.88"` in each crate's Cargo.toml, so the toolchain file was redundant for that purpose and harmful for local tooling. - Delete `rust-toolchain` so rust-analyzer uses the developer's installed stable toolchain - Update CI MSRV derivation to read from `duvet/Cargo.toml` directly instead of parsing `rustup show active-toolchain` (which read the now-deleted toolchain file) - Add `rust-version = "1.88"` to `xtask/Cargo.toml` for consistency Mirrors the fix applied in aws/s2n-quic#3180. * ci: remove stale 'Remove rust-toolchain' step from dependencies workflow
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Release Summary:
Resolved issues:
N/A
Description of changes:
rust-toolchainpinned the repository to its MSRV, and CI parsed the MSRV back out ofrustup show active-toolchain. That forced every contributor onto the MSRV toolchain, which rust-analyzer no longer supports: it requires 1.94.0 or newer and misresolves std macros against older sysroots.CI now derives the MSRV from the
rust-versionfield each crate already declares, and the threerust-toolchainfiles are removed. The MSRV is unchanged at 1.92 and the test matrix still verifies it explicitly.No CI job depended on those files; every job that compiles Rust installs and overrides its own toolchain. The
denyjob'srm rust-toolchainstep is dropped sincermfails on a missing file, andCONTRIBUTING.mdnow documents the development toolchain.tools/xdp/ebpfkeeps its nightly pin, which is a build requirement (-Zbuild-stdfor a tier 3 target), not an MSRV.Call-outs:
incompatible_msrvlint, already configured through.clippy.toml. It covers library APIs but not language features, so the MSRV matrix job remains the authority.rust-versionbelow the MSRV. Declaring higher is allowed on purpose:tools/xdpanddc/wiresharkboth sat above the repository MSRV for long stretches while their dependencies outpaced it.Testing:
cargo check --workspacepasses on stable (1.97.1) and on 1.92.0 with identical warnings.msrv=1.92andversions=["stable","beta","1.92"]. The floor check passes today, passes when a crate is raised above the MSRV, and fails when one drops below it.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.