From 1353f7fe0871fb4522ccfa8ac7eedab8b110ca9d Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Wed, 12 May 2021 17:00:39 +0200 Subject: [PATCH] not all tools require waiting for a nightly release before they can be fixed --- src/contributing.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index c07987f3..20f76176 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -272,12 +272,16 @@ tests. That would mean that, in the default state, you couldn't update the compiler without first fixing miri, rls and the other tools that the compiler builds. -Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/issues/45861) -to make all of this easy to handle. The idea is that we allow these tools to be "broken", -so that the rust-lang/rust build passes without trying to build them, then land the change -in the compiler, wait for a nightly, and go update the tools that you broke. Once you're done -and the tools are working again, you go back in the compiler and update the tools -so they can be distributed again. +Luckily, a feature was +[added to Rust's build](https://github.com/rust-lang/rust/issues/45861) to make +all of this easy to handle. The idea is that we allow these tools to be +"broken", so that the rust-lang/rust build passes without trying to build them, +then land the change in the compiler, and go update the tools that you +broke. Some tools will require waiting for a nightly release before this can +happen, while others use the builds uploaded after each bors merge and thus can +be updated immediately (check the tool's documentation for details). Once you're +done and the tools are working again, you go back in the compiler and update the +tools so they can be distributed again. This should avoid a bunch of synchronization dances and is also much easier on contributors as there's no need to block on rls/miri/other tools changes going upstream.