nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-10-30 14:01:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updating the instructions for when a tool breaks to use the new toolstate feature

Browse Source
This commit is contained in:
Sunjay Varma 2017-10-17 22:51:10 -04:00 committed by Sunjay Varma
parent 3f90c3a2cf
commit 790604adad
1 changed files with 40 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

70
CONTRIBUTING.md
View File

@ -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