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:
parent
5fabea540a
commit
9ccc69f152
|
|
@ -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
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue