Currently it allows disabling clippy and miri from being tested or built on Rust's CI. The reason they are in CI, is that they access compiler internals, and we want to know when a PR to rustc breaks the tool.
Historically rls and rustfmt were already built as part of the CI, and if you broke them, you had to
fix the tool
open a PR to the tool
have your PR changed to a long lived branch on the tool repository
point rustc's submodule to the long lived branch
wait until your rustc PR is merged
merge the long lived PR into the tool's master branch
That's a lot of steps and a lot of waiting for tool authors and rustc reviewers and CIs and breakage from other PRs...
With the toolstate.toml, you can
fix the tool
open a PR to the tool
change the toolstate.toml to account for your breakage
merge your rustc PR
wait until it hits nightly
tool authors will merge your tool PR
anyone can now point rustc's submodule to the tool's master branch in a new PR and reenable the tool in toolstate.toml
The steps might not be fewer, but you don't have to wait around for anybody anymore.
Open issues:
[ ] rls and rustfmt can't be changed to Broken, because they are distributed with rustc
[ ] clippy is not distributed
Even if rls and rustfmt are changed so they stop being distributed with rustc in case they are broken, there are a few questions of how the user experience of that is supposed to be.
rustup update nightly will update rustc, but you will have a broken tool (linker errors and whatnot)
rustup update nightly will update rustc, and the tool will simply be gone (surprising)
rustup update nightly will update rustc and the tool will be replaced by a shell script echoing "This tool is currently not available, please try again later updating your nightly
rustup update nightly will abort if there is no newer nightly with your specific combination of components
you can remove the tool manually if you still want to update
add a force option to have one of the previously mentioned behaviours
While I have anecdotal evidence that ppl like option 4, once we have a few tools and there's a breakage spree, it might be hard to find a nightly where all your tools work
Am I missing some options?
Once we have a plan on how the user experience should be, we can start talking to rustup-ppl to figure out how to teach rustup about partial rustups
For the future, where some tools will be on stable, too, I don't see any issues, because we certainly are able to get clippy building on beta/stable within 6 weeks, and I think all other tools should be capable of doing the same. We could even consider informally requiring lockstep upgrades for PRs just before the beta branching. Or we just backport a fix to the beta branch. So the initial beta might be missing a few tools, but before it becomes stable it'll have all the tools in a working condition.
The rust repository has a file for fine grained disabling of tools: https://github.com/rust-lang/rust/blob/master/src/tools/toolstate.toml
Currently it allows disabling
clippyandmirifrom being tested or built on Rust's CI. The reason they are in CI, is that they access compiler internals, and we want to know when a PR to rustc breaks the tool.Historically rls and rustfmt were already built as part of the CI, and if you broke them, you had to
That's a lot of steps and a lot of waiting for tool authors and rustc reviewers and CIs and breakage from other PRs...
With the
toolstate.toml, you cantoolstate.tomlto account for your breakageThe steps might not be fewer, but you don't have to wait around for anybody anymore.
Open issues:
Broken, because they are distributed with rustcEven if rls and rustfmt are changed so they stop being distributed with rustc in case they are broken, there are a few questions of how the user experience of that is supposed to be.
rustup update nightlywill update rustc, but you will have a broken tool (linker errors and whatnot)rustup update nightlywill update rustc, and the tool will simply be gone (surprising)rustup update nightlywill update rustc and the tool will be replaced by a shell script echoing "This tool is currently not available, please tryagain laterupdating your nightlyrustup update nightlywill abort if there is no newer nightly with your specific combination ofcomponentsWhile I have anecdotal evidence that ppl like option 4, once we have a few tools and there's a breakage spree, it might be hard to find a nightly where all your tools work
Am I missing some options?
Once we have a plan on how the user experience should be, we can start talking to
rustup-ppl to figure out how to teachrustupabout partial rustupsFor the future, where some tools will be on stable, too, I don't see any issues, because we certainly are able to get clippy building on beta/stable within 6 weeks, and I think all other tools should be capable of doing the same. We could even consider informally requiring lockstep upgrades for PRs just before the beta branching. Or we just backport a fix to the beta branch. So the initial beta might be missing a few tools, but before it becomes stable it'll have all the tools in a working condition.