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

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/building/suggested.md
View File

@ -3,6 +3,19 @@
The full bootstrapping process takes quite a while. Here are some suggestions
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`
`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
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
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
@ -147,6 +160,7 @@ crates you'll have to rebuild
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
therefore set the following in the root `Cargo.toml`:
```toml
[profile.release.package.rustc_mir_build]
opt-level = 0