rustup

rustup copied to clipboard

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

1. rust-version in Cargo.toml
2. 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

This is an interesting idea. Doing this would "reserve" the toolchain name "rust-version" but perhaps we can come up with some other term if that annoys anyone.

To make this work, Rustup would have to parse Cargo.toml which means it has to find it, and replicate Cargo's algorithms for that.

We'd have to very forgivingly parse Cargo.toml once found, and only then if we find a rust version, attempt to consider that an override.

None of this is particularly hard, but it's certainly non-trivial.

https://github.com/rust-lang/rustup/blob/master/src/config.rs#L555 has the function which finds the overrides. Starting here whoever implements this will want to understand how we find and report overrides, and then add support for this functionality.