Spelling: Rename rust to Rust (rust-lang#1288)

Author: jubnzv

Diff for: 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 for: 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 for: src/backend/monomorph.md

@@ -2,7 +2,7 @@
 
 <!-- toc -->
 
-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 for: 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 for: 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 for: src/building/how-to-build-and-run.md

@@ -120,15 +120,15 @@ 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
 ```
 
 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 for: 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 for: 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 for: 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 for: 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 for: 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 for: 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 for: 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 for: 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 for: src/test-implementation.md

@@ -2,7 +2,7 @@
 
 <!-- toc -->
 
-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 for: src/tests/intro.md

@@ -149,7 +149,7 @@ start a bash shell in the container, run `src/ci/docker/run.sh --dev <IMAGE>`
 where `<IMAGE>` 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 for: 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 for: 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 for: src/walkthrough.md

@@ -2,7 +2,7 @@
 
 <!-- toc -->
 
-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