Add section describing git hook functionality

This is a companion to [this PR](https://github.com/rust-lang/rust/pull/76356), which deals with including functionality for automatically running `tidy --bless` on each commit.

Undo editor auto-formatting and clarify git hook renaming

a word

Phrasing

Apply suggestions from code review

Co-authored-by: Camelid <37223377+camelid@users.noreply.github.com>
This commit is contained in:
Cass 2020-09-04 21:13:46 -04:00 committed by Joshua Nelson
parent 5fabea540a
commit 9ccc69f152
1 changed files with 20 additions and 6 deletions

View File

@ -3,6 +3,19 @@
The full bootstrapping process takes quite a while. Here are some suggestions The full bootstrapping process takes quite a while. Here are some suggestions
to make your life easier. to make your life easier.
## Installing a pre-commit hook
CI will automatically fail your build if it doesn't pass `tidy`, our
internal tool for ensuring code quality. If you'd like, you can install a
[Git hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)
that will automatically run `x.py test tidy --bless` on each commit, to ensure
your code is up to par. If you decide later that this behavior is
undesirable, you can delete the `pre-commit` file in `.git/hooks`.
A prebuilt git hook lives at [`src/etc/pre-commit.sh`](https://github.com/rust-lang/rust/blob/master/src/etc/pre-commit.sh) which can be copied into your `.git/hooks` folder as `pre-commit` (without the `.sh` extension!).
You can also install the hook as a step of running `x.py setup`!
## Configuring `rust-analyzer` for `rustc` ## Configuring `rust-analyzer` for `rustc`
`rust-analyzer` can help you check and format your code whenever you save `rust-analyzer` can help you check and format your code whenever you save
@ -118,7 +131,7 @@ The sequence of commands you want is as follows:
[documented previously]: ./how-to-build-and-run.md#building-the-compiler [documented previously]: ./how-to-build-and-run.md#building-the-compiler
As mentioned, the effect of `--keep-stage 1` is that we just *assume* that the As mentioned, the effect of `--keep-stage 1` is that we just _assume_ that the
old standard library can be re-used. If you are editing the compiler, this old standard library can be re-used. If you are editing the compiler, this
is almost always true: you haven't changed the standard library, after is almost always true: you haven't changed the standard library, after
all. But sometimes, it's not true: for example, if you are editing all. But sometimes, it's not true: for example, if you are editing
@ -147,6 +160,7 @@ crates you'll have to rebuild
For example, when working on `rustc_mir_build`, the `rustc_mir_build` and For example, when working on `rustc_mir_build`, the `rustc_mir_build` and
`rustc_driver` crates take the most time to incrementally rebuild. You could `rustc_driver` crates take the most time to incrementally rebuild. You could
therefore set the following in the root `Cargo.toml`: therefore set the following in the root `Cargo.toml`:
```toml ```toml
[profile.release.package.rustc_mir_build] [profile.release.package.rustc_mir_build]
opt-level = 0 opt-level = 0