mirror
/
rustc-dev-guide
mirror of https://github.com/rust-lang/rustc-dev-guide.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove detailed toolstate section 

This is already covered in detail on Forge: https://forge.rust-lang.org/infra/toolstate.html
and linked in the previous paragraph.
This commit is contained in:
jyn 2023-04-08 10:52:26 -04:00 committed by Tshepang Mbambo
parent 54a87876bd
commit 558a4f3d06
1 changed files with 1 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
src/external-repos.md
View File

@ -21,7 +21,6 @@ differently from other crates that are directly in this repo:
* [rust-analyzer](https://github.com/rust-lang/rust-analyzer)
[Miri]: https://github.com/rust-lang/miri
[Cargo]: https://github.com/rust-lang/cargo
In contrast to `submodule` dependencies
(see below for those), the `subtree` dependencies are just regular files and directories which can
@ -93,8 +92,7 @@ submodules]. The complete list may be found in the [`.gitmodules`] file. Some
of these projects are required (like `stdarch` for the standard library) and
some of them are optional (like `src/doc/book`).
Usage of submodules is discussed more in the [Using Git
chapter](git.md#git-submodules).
Usage of submodules is discussed more in the [Using Git chapter](git.md#git-submodules).
Some of the submodules are allowed to be in a "broken" state where they
either don't build or their tests don't pass, e.g. the documentation books
@ -112,49 +110,3 @@ the week leading up to the beta cut.
[The Rust Reference]: https://github.com/rust-lang/reference/
[toolstate website]: https://rust-lang-nursery.github.io/rust-toolstate/
[Toolstate chapter]: https://forge.rust-lang.org/infra/toolstate.html
### Breaking Tools Built With The Compiler
Rust's build system builds a number of tools that make use of the internals of
the compiler and that are hosted in a separate repository, and included in Rust
via git submodules (such as [Cargo]). If these tools break because of your
changes, you may run into a sort of "chicken and egg" problem. These tools rely
on the latest compiler to be built so you can't update them (in their own
repositories) 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.
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 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.example.toml` 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. (optional) Run `./x.py test src/tools/cargo` (substituting the submodule
that broke for `cargo`). 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. Wait for your PR to merge.
6. Wait for a nightly.
7. (optional) Help land your PR on the upstream repository now that your changes are in nightly.
8. (optional) Send a PR to rust-lang/rust updating the submodule.