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

Apply suggestions from code review 

Co-authored-by: Joshua Nelson <joshua@yottadb.com>
This commit is contained in:
LeSeulArtichaut 2020-09-10 17:59:53 +02:00 committed by Tshepang Lekhonkhobe
parent ee99dea822
commit 6366c1dbaa
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/contributing.md
View File

@ -92,7 +92,7 @@ to the end of the pull request description, and [@rust-highfive][rust-highfive]
In addition to being reviewed by a human, pull requests are automatically tested In addition to being reviewed by a human, pull requests are automatically tested
thanks to continuous integration (CI). Basically, every time you open and update thanks to continuous integration (CI). Basically, every time you open and update
a pull request, the CI builds the compiler and tests it against the a pull request, CI builds the compiler and tests it against the
[compiler test suite][rctd], and also performs other tests such as checking that [compiler test suite][rctd], and also performs other tests such as checking that
your pull request is in compliance with Rust's style guidelines. your pull request is in compliance with Rust's style guidelines.
@ -103,7 +103,8 @@ of the status of a particular pull request.
Rust has plenty of CI capacity, and you should never have to worry about wasting Rust has plenty of CI capacity, and you should never have to worry about wasting
computational resources each time you push a change. It is also perfectly fine computational resources each time you push a change. It is also perfectly fine
(and even encouraged!) to use the CI to test your changes if it can help your (and even encouraged!) to use the CI to test your changes if it can help your
productivity, e.g. if your machine is not very powerful. productivity. In particular, we don't recommend running the full `x.py test` suite locally,
since it takes a very long time to execute.
After someone has reviewed your pull request, they will leave an annotation After someone has reviewed your pull request, they will leave an annotation
on the pull request with an `r+`. It will look something like this: on the pull request with an `r+`. It will look something like this:
@ -136,11 +137,11 @@ should be aware of.
All pull requests should be filed against the `master` branch, except in very All pull requests should be filed against the `master` branch, except in very
particular scenarios. Unless you know for sure that you should target another particular scenarios. Unless you know for sure that you should target another
branch, `master` will be the right choice. branch, `master` will be the right choice (it's also the default).
Make sure your pull request is in compliance with Rust's style guidelines by running Make sure your pull request is in compliance with Rust's style guidelines by running
$ ./x.py test tidy $ ./x.py test tidy --bless
We recommand to make this check before every pull request (and every new commit We recommand to make this check before every pull request (and every new commit
in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) in a pull request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)