update conventions (#735)

* update conventions

* typo

Co-authored-by: Santiago Pastorino <spastorino@gmail.com>

Co-authored-by: Santiago Pastorino <spastorino@gmail.com>
This commit is contained in:
Bastian Kauschke 2020-06-05 18:06:39 +02:00 committed by GitHub
parent f9c6c1b117
commit e74b4ab3a4
1 changed files with 12 additions and 11 deletions

View File

@ -7,14 +7,18 @@ chapter covers [formatting](#formatting), [coding for correctness](#cc),
# Formatting and the tidy script # Formatting and the tidy script
rustc is slowly moving towards the [Rust standard coding style][fmt]; rustc is moving towards the [Rust standard coding style][fmt].
at the moment, however, it follows a rather more *chaotic* style. We This is enforced by the "tidy" script and can be mostly
do have some mandatory formatting conventions, which are automatically automated using `./x.py fmt`.
enforced by a script we affectionately call the "tidy" script. The
tidy script runs automatically when you do `./x.py test` and can be run As the output of [rustfmt] is not completely stable,
formatting this repository using `cargo fmt` is not recommended.
The tidy script runs automatically when you do `./x.py test` and can be run
in isolation with `./x.py test tidy`. in isolation with `./x.py test tidy`.
[fmt]: https://github.com/rust-dev-tools/fmt-rfcs [fmt]: https://github.com/rust-dev-tools/fmt-rfcs
[rustfmt]:https://github.com/rust-lang/rustfmt
<a name="copyright"></a> <a name="copyright"></a>
@ -114,12 +118,9 @@ you introduce some code following one strategy, then change it
dramatically (versus adding to it) in a later commit, that dramatically (versus adding to it) in a later commit, that
'back-and-forth' can be confusing. 'back-and-forth' can be confusing.
**Only run rustfmt on new content.** One day, we might enforce formatting **Format liberally.** While only the final commit of a PR must be correctly
for the rust-lang/rust repo. Meanwhile, we prefer that rustfmt not be run formatted, it is both easier to review and less noisy to format each commit
on existing code as that will generate large diffs and will make git blame individually using `./x.py fmt`.
harder to sift through. However, running `rustfmt` on new content, e.g. a
new file or a largely new part of a file is ok. Small formatting adjustments
nearby code you are already changing for other purposes are also ok.
**No merges.** We do not allow merge commits into our history, other **No merges.** We do not allow merge commits into our history, other
than those by bors. If you get a merge conflict, rebase instead via a than those by bors. If you get a merge conflict, rebase instead via a