Description
Problem you are trying to solve
Now that rust-version is stable it makes sense to have a CI task/job that asserts this commitment. In that case, one would need to set up a CI config that runs tests on the selected Rust version. Usually, it means that the specific version will be specified twice
rust-version
inCargo.toml
- Somewhere in CI configuration.
And they need to be in sync to make sense. This is where extra work is required and that may be avoided.
Solution you'd like
I suggest teaching cargo
to understand the +rust-version
parameter, alongside the +stable
, +nightly
, and friends. When specified it will cause cargo to use the Rust toolchain referenced in the rust-version
parameter. (And installing it on demand as it does today when used with other +toolchain
parameters).
If used for crates that lack rust-version
parameter it will fall back to otherwise default toolchain configured for this crate.
As a result, the potential disagreement between CI and rust-version
will be avoided completely, better usability, less time wasted, etc
Notes
This issue was originally opened as rust-lang/cargo#10012, but rustup is the right place to solve it