CI should be pinned to a particular rustc version

[RalfJung]

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.

[adamgemmell]

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 fmt isn't being run on at least some stdarch crates in rust-lang/rust.

[RalfJung]

I'd prefer to see this handled by running more CI in rust-lang/rust if possible.

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]

because cargo fmt isn't being run on at least some stdarch crates in rust-lang/rust.

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]

Makes sense, thanks. I'll follow up (ask Jakub) why our sync isn't handling that

[RalfJung]

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.