diff --git a/src/about-this-guide.md b/src/about-this-guide.md index e015302c0..b2c71866c 100644 --- a/src/about-this-guide.md +++ b/src/about-this-guide.md @@ -59,8 +59,8 @@ please see the corresponding [subsection on writing documentation in this guide] You might also find the following sites useful: - [rustc API docs] -- rustdoc documentation for the compiler -- [Forge] -- contains documentation about rust infrastructure, team procedures, and more -- [compiler-team] -- the home-base for the rust compiler team, with description +- [Forge] -- contains documentation about Rust infrastructure, team procedures, and more +- [compiler-team] -- the home-base for the Rust compiler team, with description of the team procedures, active working groups, and the team calendar. - [std-dev-guide] -- a similar guide for developing the standard library. diff --git a/src/backend/codegen.md b/src/backend/codegen.md index 8e18ca242..1a6c2fa76 100644 --- a/src/backend/codegen.md +++ b/src/backend/codegen.md @@ -3,7 +3,7 @@ Code generation or "codegen" is the part of the compiler that actually generates an executable binary. Usually, rustc uses LLVM for code generation; there is also support for [Cranelift]. The key is that rustc doesn't implement -codegen itself. It's worth noting, though, that in the rust source code, many +codegen itself. It's worth noting, though, that in the Rust source code, many parts of the backend have `codegen` in their names (there are no hard boundaries). diff --git a/src/backend/monomorph.md b/src/backend/monomorph.md index a2918b608..7111c634a 100644 --- a/src/backend/monomorph.md +++ b/src/backend/monomorph.md @@ -2,7 +2,7 @@ -As you probably know, rust has a very expressive type system that has extensive +As you probably know, Rust has a very expressive type system that has extensive support for generic types. But of course, assembly is not generic, so we need to figure out the concrete types of all the generics before the code can execute. @@ -23,7 +23,7 @@ The result is fast programs, but it comes at the cost of compile time (creating all those copies can take a while) and binary size (all those copies might take a lot of space). -Monomorphization is the first step in the backend of the rust compiler. +Monomorphization is the first step in the backend of the Rust compiler. ## Collection diff --git a/src/building/bootstrapping.md b/src/building/bootstrapping.md index 460776e51..48f501a02 100644 --- a/src/building/bootstrapping.md +++ b/src/building/bootstrapping.md @@ -110,7 +110,7 @@ bootstrapping the compiler. When you use the bootstrap system, you'll call it through `x.py`. However, most of the code lives in `src/bootstrap`. `bootstrap` has a difficult problem: it is written in Rust, but yet it is run -before the rust compiler is built! To work around this, there are two +before the Rust compiler is built! To work around this, there are two components of bootstrap: the main one written in rust, and `bootstrap.py`. `bootstrap.py` is what gets run by `x.py`. It takes care of downloading the `stage0` compiler, which will then build the bootstrap binary written in diff --git a/src/building/compiler-documenting.md b/src/building/compiler-documenting.md index 0efe2fce6..f921cd089 100644 --- a/src/building/compiler-documenting.md +++ b/src/building/compiler-documenting.md @@ -50,6 +50,6 @@ documentation for internal compiler items will also be built. ### Compiler Documentation -The documentation for the rust components are found at [rustc doc]. +The documentation for the Rust components are found at [rustc doc]. [rustc doc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index cd4891358..93ebb487e 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -120,7 +120,7 @@ Options: --on-fail CMD command to run on failure --stage N stage to build --keep-stage N stage to keep without recompiling - --src DIR path to the root of the rust checkout + --src DIR path to the root of the Rust checkout -j, --jobs JOBS number of jobs to run in parallel -h, --help print this help message ``` @@ -128,7 +128,7 @@ Options: For hacking, often building the stage 1 compiler is enough, which saves a lot of time. But for final testing and release, the stage 2 compiler is used. -`./x.py check` is really fast to build the rust compiler. +`./x.py check` is really fast to build the Rust compiler. It is, in particular, very useful when you're doing some kind of "type-based refactoring", like renaming a method, or changing the signature of some function. @@ -150,7 +150,7 @@ What this command does is the following: - Build `std` using the stage1 compiler (cannot use incremental) This final product (stage1 compiler + libs built using that compiler) -is what you need to build other rust programs (unless you use `#![no_std]` or +is what you need to build other Rust programs (unless you use `#![no_std]` or `#![no_core]`). The command includes the `-i` switch which enables incremental compilation. diff --git a/src/building/suggested.md b/src/building/suggested.md index bae98aa04..14e0410de 100644 --- a/src/building/suggested.md +++ b/src/building/suggested.md @@ -199,7 +199,7 @@ do not get shared. They will still be cloned multiple times. [worktrees]: https://git-scm.com/docs/git-worktree -Given you are inside the root directory for your rust repository, you can +Given you are inside the root directory for your Rust repository, you can create a "linked working tree" in a new "rust2" directory by running the following command: diff --git a/src/compiler-src.md b/src/compiler-src.md index b621dde7c..94add9aac 100644 --- a/src/compiler-src.md +++ b/src/compiler-src.md @@ -76,7 +76,7 @@ crates, just like a normal Rust crate. One final thing: [`src/llvm-project`] is a submodule for our fork of LLVM. During bootstrapping, LLVM is built and the [`compiler/rustc_llvm`] crate -contains rust wrappers around LLVM (which is written in C++), so that the +contains Rust wrappers around LLVM (which is written in C++), so that the compiler can interface with it. Most of this book is about the compiler, so we won't have any further @@ -183,7 +183,7 @@ from `src/tools/`, such as [`tidy`] or [`compiletest`]. ## Other There are a lot of other things in the `rust-lang/rust` repo that are related -to building a full rust distribution. Most of the time you don't need to worry +to building a full Rust distribution. Most of the time you don't need to worry about them. These include: diff --git a/src/compiletest.md b/src/compiletest.md index b85aa09c2..2d34ea04f 100644 --- a/src/compiletest.md +++ b/src/compiletest.md @@ -178,7 +178,7 @@ function found in the `TestCx` implementation block, located in } fn check_correct_failure_status(&self, proc_res: &ProcRes) { -- // The value the rust runtime returns on failure +- // The value the Rust runtime returns on failure - const RUST_ERR: i32 = 101; - if proc_res.status.code() != Some(RUST_ERR) { + let expected_status = Some(self.props.failure_status); diff --git a/src/contributing.md b/src/contributing.md index 8f6d1d6d8..2d6511321 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -214,7 +214,7 @@ is modified to move the files from the specified directory to the tool repo root A `subtree pull` takes all changes since the last `subtree pull` from the tool repo and adds these commits to the rustc repo along with a merge commit that moves -the tool changes into the specified directory in the rust repository. +the tool changes into the specified directory in the Rust repository. It is recommended that you always do a push first and get that merged to the tool master branch. Then, when you do a pull, the merge works without conflicts. diff --git a/src/crates-io.md b/src/crates-io.md index bc59bfeed..62143defa 100644 --- a/src/crates-io.md +++ b/src/crates-io.md @@ -1,6 +1,6 @@ # crates.io Dependencies -The rust compiler supports building with some dependencies from `crates.io`. +The Rust compiler supports building with some dependencies from `crates.io`. For example, `log` and `env_logger` come from `crates.io`. In general, you should avoid adding dependencies to the compiler for several diff --git a/src/diagnostics/diagnostic-items.md b/src/diagnostics/diagnostic-items.md index 93a0194d9..b5cba717f 100644 --- a/src/diagnostics/diagnostic-items.md +++ b/src/diagnostics/diagnostic-items.md @@ -29,7 +29,7 @@ reference [*How To Use Diagnostic Items*](#how-to-use-diagnostic-items). A new diagnostic item can be added with these two steps: -1. Find the target item inside the rust repo. Now add the diagnostic item as a string via the +1. Find the target item inside the Rust repo. Now add the diagnostic item as a string via the `rustc_diagnostic_item` attribute. This can sometimes cause compilation errors while running tests. These errors can be avoided by using the `cfg_attr` attribute with the `not(test)` condition (it's fine adding then for all `rustc_diagnostic_item` attributes as a preventive diff --git a/src/macro-expansion.md b/src/macro-expansion.md index 2f42ad9b9..e3b5a27e6 100644 --- a/src/macro-expansion.md +++ b/src/macro-expansion.md @@ -216,7 +216,7 @@ handle names defined _within a macro_. In particular, a hygienic macro system prevents errors due to names introduced within a macro. Rust macros are hygienic in that they do not allow one to write the sorts of bugs above. -At a high level, hygiene within the rust compiler is accomplished by keeping +At a high level, hygiene within the Rust compiler is accomplished by keeping track of the context where a name is introduced and used. We can then disambiguate names based on that context. Future iterations of the macro system will allow greater control to the macro author to use that context. For example, diff --git a/src/overview.md b/src/overview.md index 5c88722ef..02e56ca03 100644 --- a/src/overview.md +++ b/src/overview.md @@ -5,7 +5,7 @@ This chapter is about the overall process of compiling a program -- how everything fits together. -The rust compiler is special in two ways: it does things to your code that +The Rust compiler is special in two ways: it does things to your code that other compilers don't do (e.g. borrow checking) and it has a lot of unconventional implementation choices (e.g. queries). We will talk about these in turn in this chapter, and in the rest of the guide, we will look at all the @@ -225,7 +225,7 @@ interned. ### Queries -The first big implementation choice is the _query_ system. The rust compiler +The first big implementation choice is the _query_ system. The Rust compiler uses a query system which is unlike most textbook compilers, which are organized as a series of passes over the code that execute sequentially. The compiler does this to make incremental compilation possible -- that is, if the diff --git a/src/test-implementation.md b/src/test-implementation.md index 1a9283b59..09a66cdc9 100644 --- a/src/test-implementation.md +++ b/src/test-implementation.md @@ -2,7 +2,7 @@ -Today, rust programmers rely on a built in attribute called `#[test]`. All +Today, Rust programmers rely on a built in attribute called `#[test]`. All you have to do is mark a function as a test and include some asserts like so: ```rust,ignore diff --git a/src/tests/intro.md b/src/tests/intro.md index d92f042e4..efce3a658 100644 --- a/src/tests/intro.md +++ b/src/tests/intro.md @@ -149,7 +149,7 @@ start a bash shell in the container, run `src/ci/docker/run.sh --dev ` where `` is one of the directory names in `src/ci/docker` (for example `x86_64-gnu` is a fairly standard Ubuntu environment). -The docker script will mount your local rust source tree in read-only mode, +The docker script will mount your local Rust source tree in read-only mode, and an `obj` directory in read-write mode. All of the compiler artifacts will be stored in the `obj` directory. The shell will start out in the `obj` directory. From there, you can run `../src/ci/run.sh` which will run the build @@ -301,7 +301,7 @@ or could cause breakage. If you are unsure, feel free to ask your PR's reviewer. ### Requesting Crater Runs -The rust team maintains a few machines that can be used for running crater runs +The Rust team maintains a few machines that can be used for running crater runs on the changes introduced by a PR. If your PR needs a crater run, leave a comment for the triage team in the PR thread. Please inform the team whether you require a "check-only" crater run, a "build only" crater run, or a diff --git a/src/tests/running.md b/src/tests/running.md index ba87c5f9a..cd8f12ba1 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -124,7 +124,7 @@ may invoke `x.py` with the `--test-args` option: ./x.py test src/test/ui --test-args issue-1234 ``` -Under the hood, the test runner invokes the standard rust test runner +Under the hood, the test runner invokes the standard Rust test runner (the same one you get with `#[test]`), so this command would wind up filtering for tests that include "issue-1234" in the name. (Thus `--test-args` is a good way to run a collection of related tests.) diff --git a/src/ty.md b/src/ty.md index 87d653a74..95141b6f2 100644 --- a/src/ty.md +++ b/src/ty.md @@ -40,7 +40,7 @@ different [`Span`s][span] (locations). [span]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html **Example: `fn foo(x: &u32) -> &u32`** In addition, HIR might have information left out. This type -`&u32` is incomplete, since in the full rust type there is actually a lifetime, but we didn’t need +`&u32` is incomplete, since in the full Rust type there is actually a lifetime, but we didn’t need to write those lifetimes. There are also some elision rules that insert information. The result may look like `fn foo<'a>(x: &'a u32) -> &'a u32`. diff --git a/src/walkthrough.md b/src/walkthrough.md index 8f5dc525e..84cb1296f 100644 --- a/src/walkthrough.md +++ b/src/walkthrough.md @@ -2,7 +2,7 @@ -There are _a lot_ of ways to contribute to the rust compiler, including fixing +There are _a lot_ of ways to contribute to the Rust compiler, including fixing bugs, improving performance, helping design features, providing feedback on existing features, etc. This chapter does not claim to scratch the surface. Instead, it walks through the design and implementation of a new feature. Not @@ -38,7 +38,7 @@ fn main() { So basically, the `$(pat)?` matcher in the macro means "this pattern can occur 0 or 1 times", similar to other regex syntaxes. -There were a number of steps to go from an idea to stable rust feature. Here is +There were a number of steps to go from an idea to stable Rust feature. Here is a quick list. We will go through each of these in order below. As I mentioned before, not all of these are needed for every type of contribution. @@ -55,9 +55,9 @@ before, not all of these are needed for every type of contribution. feature on the nightly compiler and in `std`, there may be additional feedback about design choice that might be adjusted. This particular feature went [through][impl2] a [number][impl3] of [iterations][impl4]. -- **Stabilization** When your feature has baked enough, a rust team member may +- **Stabilization** When your feature has baked enough, a Rust team member may [propose to stabilize it][merge]. If there is consensus, this is done. -- **Relax** Your feature is now a stable rust feature! +- **Relax** Your feature is now a stable Rust feature! [prerfc]: https://internals.rust-lang.org/t/pre-rfc-at-most-one-repetition-macro-patterns/6557 [rfc]: https://github.com/rust-lang/rfcs/pull/2298 @@ -70,7 +70,7 @@ before, not all of these are needed for every type of contribution. ## Pre-RFC and RFC > NOTE: In general, if you are not proposing a _new_ feature or substantial -> change to rust or the ecosystem, you don't need to follow the RFC process. +> change to Rust or the ecosystem, you don't need to follow the RFC process. > Instead, you can just jump to [implementation](#impl). > > You can find the official guidelines for when to open an RFC [here][rfcwhen]. @@ -79,7 +79,7 @@ before, not all of these are needed for every type of contribution. An RFC is a document that describes the feature or change you are proposing in detail. Anyone can write an RFC; the process is the same for everyone, -including rust team members. +including Rust team members. To open an RFC, open a PR on the [rust-lang/rfcs](https://github.com/rust-lang/rfcs) repo on GitHub. You can @@ -122,7 +122,7 @@ itself to reflect the course of the discussion (e.g. new alternatives or prior work may be added or you may decide to change parts of the proposal itself). In the end, when the discussion seems to reach a consensus and die down a bit, -a rust team member may propose to move to "final comment period" (FCP) with one +a Rust team member may propose to move to "final comment period" (FCP) with one of three possible dispositions. This means that they want the other members of the appropriate teams to review and comment on the RFC. More discussion may ensue, which may result in more changes or unresolved questions being added. At @@ -137,7 +137,7 @@ disposition is adopted. Here are the three possible dispositions: This is not a reflection on you, but rather a community decision that rust will go a different direction. - _Postpone_: there is interest in going this direction but not at the moment. - This happens most often because the appropriate rust team doesn't have the + This happens most often because the appropriate Rust team doesn't have the bandwidth to shepherd the feature through the process to stabilization. Often this is the case when the feature doesn't fit into the team's roadmap. Postponed ideas may be revisited later. @@ -181,7 +181,7 @@ gate is removed when the feature is stabilized. make your changes/improvements. When you open a PR on the [rust-lang/rust], a bot will assign your PR to a -review. If there is a particular rust team member you are working with, you can +review. If there is a particular Rust team member you are working with, you can request that reviewer by leaving a comment on the thread with `r? @reviewer-github-id` (e.g. `r? @eddyb`). If you don't know who to request, don't request anyone; the bot will assign someone automatically based on which files you changed. @@ -224,7 +224,7 @@ be proposed and unresolved questions may become resolved. Updates/changes go through the same process for implementing any other changes, as described above (i.e. submit a PR, go through review, wait for `@bors`, etc). -Some changes may be major enough to require an FCP and some review by rust team +Some changes may be major enough to require an FCP and some review by Rust team members. For the `?` macro feature, we went through a few different iterations after the