From 355d54eb85c6c86832b4d7b9a60f31916abe695e Mon Sep 17 00:00:00 2001 From: Cass Date: Fri, 4 Sep 2020 21:13:46 -0400 Subject: [PATCH] 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> --- src/building/suggested.md | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/src/building/suggested.md b/src/building/suggested.md index 2ebdecd07..58996e639 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -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 @@ -82,7 +95,7 @@ directories you have [setup a worktree for]. You may need to use the pinned nightly version from `src/stage0.txt`, but often the normal `nightly` channel will work. -**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, +**Note** see [the section on vscode] for how to configure it with this real rustfmt `x.py` uses, and [the section on rustup] for how to setup `rustup` toolchain for your bootstrapped compiler **Note** This does _not_ allow you to build `rustc` with cargo directly. You @@ -100,7 +113,7 @@ Sometimes just checking whether the compiler builds is not enough. A common example is that you need to add a `debug!` statement to inspect the value of some state or better understand the problem. In that case, you really need -a full build. By leveraging incremental, though, you can often get +a full build. By leveraging incremental, though, you can often get these builds to complete very fast (e.g., around 30 seconds). The only catch is this requires a bit of fudging and may produce compilers that don't work (but that is easily detected and fixed). @@ -118,10 +131,10 @@ 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 +all. But sometimes, it's not true: for example, if you are editing the "metadata" part of the compiler, which controls how the compiler encodes types and other states into the `rlib` files, or if you are editing things that wind up in the metadata (such as the definition of @@ -131,7 +144,7 @@ the MIR). using `--keep-stage 1`** -- for example, strange [ICEs](../appendix/glossary.html#ice) or other panics. In that case, you should simply remove the `--keep-stage 1` from the command and -rebuild. That ought to fix the problem. +rebuild. That ought to fix the problem. You can also use `--keep-stage 1` when running tests. Something like this: @@ -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 @@ -218,6 +232,6 @@ Note that you need to have the LLVM `FileCheck` tool installed, which is used for codegen tests. This tool is normally built with LLVM, but if you use your own preinstalled LLVM, you will need to provide `FileCheck` in some other way. On Debian-based systems, you can install the `llvm-N-tools` package (where `N` -is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify +is the LLVM version number, e.g. `llvm-8-tools`). Alternately, you can specify the path to `FileCheck` with the `llvm-filecheck` config item in `config.toml` or you can disable codegen test with the `codegen-tests` item in `config.toml`.