Spelling: Rename rust to Rust (#1288)

Author: jubnzv

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.
 

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).
 

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
 

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

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/

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.

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:
 

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:

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);

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.