Repository navigation
CI should be pinned to a particular rustc version #2218
Description
It is currently very common that one makes a stdarch PR and CI fails despite the PR being correct -- in other words, stdarch master regularly fails its own CI. This is caused by CI automatically testing against the latest nightly version of rustc, while this repo uses tons of very unstable features. This is not a great contributor experience.
It would be better if CI tested some pinned rustc nightly / commit, so that one can be sure that red CI in a PR is actually caused by the changes on that PR.
Activity
adamgemmell commentedon Sep 7, 2026
I think this approach isn't ideal for people contributing directly to stdarch, as code that works on the pinned rustc but not the latest nightly would block subtree syncs into rust-lang/rust.
I'd prefer to see this handled by running more CI in rust-lang/rust if possible. This latest occurrence is because the subtree hasn't been synced in a little bit, but that's currently blocked because
cargo fmtisn't being run on at least some stdarch crates in rust-lang/rust.RalfJung commentedon Sep 7, 2026
This would indeed help quite a bit, but it's not a real fix for this problem.
FWIW, other subtrees like clippy and Miri pin a toolchain for their own CI.
RalfJung commentedon Sep 7, 2026
FWIW that is expected. We don't usually format subtrees in the main repo. Instead the syncs usually do formatting if new incoming code.
You can ask for stdarch to be formatted in the main repo of course, but the rustfmt configuration & version may be different so we usually avoid that.
adamgemmell commentedon Sep 7, 2026
Makes sense, thanks. I'll follow up (ask Jakub) why our sync isn't handling that
RalfJung commentedon Sep 7, 2026
FWIW it is also pretty normal that one has to do a bit of editing of such a sync by pushing some more commits to it. As long as you don't force-push, that'll work just fine.