Skip to content

Commit

Permalink
Updating the instructions for when a tool breaks to use the new tools…
Browse files Browse the repository at this point in the history
…tate feature
  • Loading branch information
sunjay committed Oct 18, 2017
1 parent 3f90c3a commit 790604a
Showing 1 changed file with 40 additions and 30 deletions.
70 changes: 40 additions & 30 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -363,46 +363,56 @@ outside the submodule.
It can also be more convenient during development to set `submodules = false`
in the `config.toml` to prevent `x.py` from resetting to the original branch.

#### Breaking rustfmt or rls
[breaking-rustfmt-or-rls]: #breaking-rustfmt-or-rls
#### Breaking Tools Built With The Compiler
[breaking-tools-built-with-the-compiler]: #breaking-tools-built-with-the-compiler

Rust's build system also builds the
[RLS](https://github.com/rust-lang-nursery/rls)
and [rustfmt](https://github.com/rust-lang-nursery/rustfmt). If these tools
Rust's build system builds a number of tools that make use of the
internals of the compiler. This includes clippy,
[RLS](https://github.com/rust-lang-nursery/rls) and
[rustfmt](https://github.com/rust-lang-nursery/rustfmt). If these tools
break because of your changes, you may run into a sort of "chicken and egg"
problem. Both tools rely on the latest compiler to be built so you can't update
them until the changes you are making to the compiler land. In the meantime, you
can't land your changes to the compiler because the build won't pass until those
tools are fixed.
problem. These tools rely on the latest compiler to be built so you can't update
them to reflect your changes to the compiler until those changes are merged into
the compiler. At the same time, you can't get your changes merged into the compiler
because the rust-lang/rust build won't pass until those tools build and pass their
tests.

That means that, in the default state, you can't update the compiler without
fixing rustfmt and rls first.
That means that, in the default state, you can't update the compiler without first
fixing rustfmt, rls and the other tools that the compiler builds.

When this happens, follow these steps:
Luckily, a feature was [added to Rust's build](https://github.com/rust-lang/rust/pull/45243)
to make all of this easy to handle. The idea is that you mark the tools as "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 change the tools back
from "broken".

1. First, if it doesn't exist already, create a `config.toml` by copying
This should avoid a bunch of synchronization dances and is also much easier on contributors as
there's no need to block on rls/rustfmt/other tools changes going upstream.

Here are those same steps in detail:

1. (optional) First, if it doesn't exist already, create a `config.toml` by copying
`config.toml.example` in the root directory of the Rust repository.
Set `submodules = false` in the `[build]` section. This will prevent `x.py`
from resetting to the original branch after you make your changes. If you
need to [update any submodules to their latest versions][updating-submodules],
see the section of this file about that for more information.
2. Run `./x.py test src/tools/rustfmt`. Fix any errors in the submodule itself
(the `src/tools/rustfmt` directory) until it works.
3. Run `./x.py test src/tools/rls`. Fix any errors in the submodule itself
(the `src/tools/rls` directory) until it works.
4. Make a commit for `rustfmt`, if necessary, and send a PR to the master
branch of rust-lang-nursery/rustfmt
5. Do the same, if necessary for the RLS
6. A maintainer of rls/rustfmt will **not** merge the PR. The PR can't be
merged because CI will be broken. Instead a new branch will be created,
and the PR will be pushed to the branch (the PR is left open)
7. On your branch, update the rls/rustfmt submodules to these branches
8. Commit the changes, update your PR to rust-lang/rust
9. Wait for the branch to merge
10. Wait for a nightly
11. A maintainer of rls/rustfmt will merge the original PRs to rls/rustfmt
12. Eventually the rls/rustfmt submodules will get re-updated back to the
master branch
2. (optional) Run `./x.py test src/tools/rustfmt` (substituting the submodule
that broke for `rustfmt`). Fix any errors in the submodule (and possibly others).
3. (optional) Make commits for your changes and send them to upstream repositories as a PR.
4. (optional) Maintainers of these submodules will **not** merge the PR. The PR can't be
merged because CI will be broken. You'll want to write a message on the PR referencing
your change, and how the PR should be merged once your change makes it into a nightly.
5. Update `src/tools/toolstate.toml` to indicate that the tool in question is "broken",
that will disable building it on CI. See the documentation in that file for the exact
configuration values you can use.
6. Commit the changes to `src/tools/toolstate.toml`, **do not update submodules in your commit**,
and then update the PR you have for rust-lang/rust.
7. Wait for your PR to merge.
8. Wait for a nightly
9. (optional) Help land your PR on the upstream repository now that your changes are in nightly.
10. (optional) Send a PR to rust-lang/rust updating the submodule, reverting `src/tools/toolstate.toml` back to a "building" or "testing" state.

#### Updating submodules
[updating-submodules]: #updating-submodules
Expand Down

0 comments on commit 790604a

Please sign in to comment.