Whitespace cleanup and some punctuation

Author: igaray

README.md

@@ -100,7 +100,7 @@ but we leave these instructions for when we do it again in the future.
 
 7. Click on the log and Ctrl-f to get a search box in the log
 
-8. Search for rustc-dev-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log
+8. Search for rustc-dev-guide. This gets you to the place where the links are checked. It is usually ~11K lines into the log.
 
 9. Look at the links in the log near that point in the log
 

src/about-this-guide.md

@@ -47,7 +47,7 @@ a correction!
 If you do contribute to the guide, please see the corresponding
 [subsection on writing documentation in this guide].
 
-[subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide.
+[subsection on writing documentation in this guide]: contributing.md#contributing-to-rustc-dev-guide
 
 > “‘All conditioned things are impermanent’ — when one sees this with wisdom, one turns away from
 > suffering.” _The Dhammapada, verse 277_

src/backend/implicit-caller-location.md

@@ -3,9 +3,9 @@
 <!-- toc -->
 
 Approved in [RFC 2091], this feature enables the accurate reporting of caller location during panics
-initiated from functions like `Option::unwrap`, `Result::expect`, and `Index::index`. This feature 
-adds the [`#[track_caller]`][attr-reference] attribute for functions, the 
-[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly 
+initiated from functions like `Option::unwrap`, `Result::expect`, and `Index::index`. This feature
+adds the [`#[track_caller]`][attr-reference] attribute for functions, the
+[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly
 [`core::panic::Location::caller`][wrapper] wrapper.
 
 ## Motivating Example
@@ -30,25 +30,25 @@ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
 As of 1.42, we get a much more helpful message:
 
 ```
-$ rustc +1.42.0 example.rs; example.exe 
+$ rustc +1.42.0 example.rs; example.exe
 thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', example.rs:3:5
 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 ```
 
 These error messages are achieved through a combination of changes to `panic!` internals to make use
-of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard 
+of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard
 library which propagate caller information.
 
 ## Reading Caller Location
 
 Previously, `panic!` made use of the `file!()`, `line!()`, and `column!()` macros to construct a
 [`Location`] pointing to where the panic occurred. These macros couldn't be given an overridden
-location, so functions which intentionally invoked `panic!` couldn't provide their own location, 
+location, so functions which intentionally invoked `panic!` couldn't provide their own location,
 hiding the actual source of error.
 
-Internally, `panic!()` now calls [`core::panic::Location::caller()`][wrapper] to find out where it 
-was expanded. This function is itself annotated with `#[track_caller]` and wraps the 
-[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest 
+Internally, `panic!()` now calls [`core::panic::Location::caller()`][wrapper] to find out where it
+was expanded. This function is itself annotated with `#[track_caller]` and wraps the
+[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest
 explained in terms of how it works in a `const` context.
 
 ## Caller Location in `const`
@@ -58,20 +58,20 @@ to find the right location and allocating a const value to return.
 
 ### Finding the right `Location`
 
-In a const context we "walk up the stack" from where the intrinsic is invoked, stopping when we 
+In a const context we "walk up the stack" from where the intrinsic is invoked, stopping when we
 reach the first function call in the stack which does *not* have the attribute. This walk is in
 [`InterpCx::find_closest_untracked_caller_location()`][const-find-closest].
 
-Starting at the bottom, we iterate up over stack [`Frame`][const-frame]s in the 
+Starting at the bottom, we iterate up over stack [`Frame`][const-frame]s in the
 [`InterpCx::stack`][const-stack], calling
-[`InstanceDef::requires_caller_location`][requires-location] on the 
+[`InstanceDef::requires_caller_location`][requires-location] on the
 [`Instance`s from each `Frame`][frame-instance]. We stop once we find one that returns `false` and
 return the span of the *previous* frame which was the "topmost" tracked function.
 
 ### Allocating a static `Location`
 
-Once we have a `Span`, we need to allocate static memory for the `Location`, which is performed by 
-the [`TyCtxt::const_caller_location()`][const-location-query] query. Internally this calls 
+Once we have a `Span`, we need to allocate static memory for the `Location`, which is performed by
+the [`TyCtxt::const_caller_location()`][const-location-query] query. Internally this calls
 [`InterpCx::alloc_caller_location()`][alloc-location] and results in a unique
 [memory kind][location-memory-kind] (`MemoryKind::CallerLocation`). The SSA codegen backend is able
 to emit code for these same values, and we use this code there as well.
@@ -80,14 +80,14 @@ Once our `Location` has been allocated in static memory, our intrinsic returns a
 
 ## Generating code for `#[track_caller]` callees
 
-To generate efficient code for a tracked function and its callers, we need to provide the same 
+To generate efficient code for a tracked function and its callers, we need to provide the same
 behavior from the intrinsic's point of view without having a stack to walk up at runtime. We invert
 the approach: as we grow the stack down we pass an additional argument to calls of tracked functions
 rather than walking up the stack when the intrinsic is called. That additional argument can be
 returned wherever the caller location is queried.
 
 The argument we append is of type `&'static core::panic::Location<'static>`. A reference was chosen
-to avoid unnecessary copying because a pointer is a third the size of 
+to avoid unnecessary copying because a pointer is a third the size of
 `std::mem::size_of::<core::panic::Location>() == 24` at time of writing.
 
 When generating a call to a function which is tracked, we pass the location argument the value of
@@ -153,12 +153,12 @@ probably the best we can do without modifying fully-stabilized type signatures.
 
 > *Note:* We always emit a [`ReifyShim`] when taking a pointer to a tracked function. While the
 > constraint here is imposed by codegen contexts, we don't know during MIR construction of the shim
-> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe 
+> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe
 > to ignore shim). Even if we did know, the results from const and codegen contexts must agree.
 
 ## The Attribute
 
-The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the 
+The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the
 function:
 
 * has the `"Rust"` ABI (as opposed to e.g., `"C"`)
@@ -173,7 +173,7 @@ used in both const and codegen contexts to ensure correct propagation.
 
 When applied to trait method implementations, the attribute works as it does for regular functions.
 
-When applied to a trait method prototype, the attribute applies to all implementations of the 
+When applied to a trait method prototype, the attribute applies to all implementations of the
 method. When applied to a default trait method implementation, the attribute takes effect on
 that implementation *and* any overrides.
 
@@ -205,14 +205,14 @@ trait TrackedFourWays {
         assert_tracked!();
     }
 
-    /// Overrides of this implementation are tracked (it is too). 
+    /// Overrides of this implementation are tracked (it is too).
     #[track_caller]
     fn default_tracked_to_override() {
         assert_tracked!();
     }
 }
 
-/// This impl uses the default impl for `default_tracked` and provides its own for 
+/// This impl uses the default impl for `default_tracked` and provides its own for
 /// `default_tracked_to_override`.
 impl TrackedFourWays for () {
     fn blanket_tracked() {
@@ -255,7 +255,7 @@ up on the tracking issue. During the course of implementing that, it was also di
 implementation was possible without modifying the number of arguments in a function's MIR, which
 would simplify later stages and unlock use in traits.
 
-Because the RFC's implementation strategy could not readily support traits, the semantics were not 
+Because the RFC's implementation strategy could not readily support traits, the semantics were not
 originally specified. They have since been implemented following the path which seemed most correct
 to the author and reviewers.
 

src/backend/monomorph.md

@@ -59,12 +59,12 @@ units](../appendix/glossary.md#codegen-unit).
 
 ## Codegen Unit (CGU) partitioning
 
-For better incremental build times, the CGU partitioner creates two CGU for each source level 
-modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e. 
+For better incremental build times, the CGU partitioner creates two CGU for each source level
+modules. One is for "stable" i.e. non-generic code and the other is more volatile code i.e.
 monoporphized/specialized instances.
 
 For depenencies, consider Crate A and Crate B, such that Crate B depends on Crate A.
-The following table lists different scenarios for a function in Crate A that might be used by one 
+The following table lists different scenarios for a function in Crate A that might be used by one
 or more modules in Crate B.
 
 | Crate A function | Behavior |

src/borrow_check/moves_and_initialization/move_paths.md

@@ -9,11 +9,11 @@ at the field granularity:
 ```rust,ignore
 fn foo() {
     let a: (Vec<u32>, Vec<u32>) = (vec![22], vec![44]);
-    
+
     // a.0 and a.1 are both initialized
-    
+
     let b = a.0; // moves a.0
-    
+
     // a.0 is not initialized, but a.1 still is
 
     let c = a.0; // ERROR
@@ -75,7 +75,7 @@ there is no need for a [`MovePathIndex`]. Some examples:
   there would be no move-path for `foo[1]`.
 - You cannot move from inside of a borrowed reference, so if we have e.g. `foo: &String`,
   there would be no move-path for `*foo`.
-  
+
 These rules are enforced by the [`move_path_for`] function, which
 converts a [`Place`] into a [`MovePathIndex`] -- in error cases like
 those just discussed, the function returns an `Err`. This in turn
@@ -104,7 +104,7 @@ of [`MoveData`]. There are two different methods:
   [`LookupResult`] indicating the closest path it was able to find
   that exists (e.g., for `foo[1]`, it might return just the path for
   `foo`).
-  
+
 [`find`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find
 [`find_local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/dataflow/move_paths/struct.MovePathLookup.html#method.find_local
 [`mir::Local`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Local.html
@@ -122,7 +122,7 @@ just over the paths that are **actually referenced** in the source,
 not all **possible** paths that could have been referenced). These
 references are used for example in the
 [`find_in_move_path_or_its_descendants`] function, which determines
-whether a move-path (e.g., `a.b`) or any child of that move-path 
+whether a move-path (e.g., `a.b`) or any child of that move-path
 (e.g.,`a.b.c`) matches a given predicate.
 
 [`Place`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Place.html

src/compiler-debugging.md

@@ -11,14 +11,14 @@ chapter](./backend/debugging.md)).
 
 ## Configuring the compiler
 
-By default, rustc is built without most debug information. To enable debug info, 
-set `debug = true` in your config.toml. 
+By default, rustc is built without most debug information. To enable debug info,
+set `debug = true` in your config.toml.
 
-Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`, 
-`debug-logging`, etc.) which can be individually tweaked if you want to, but many people 
+Setting `debug = true` turns on many different debug options (e.g., `debug-assertions`,
+`debug-logging`, etc.) which can be individually tweaked if you want to, but many people
 simply set `debug = true`. Check out the comments in config.toml.example for more info.
 
-You will need to rebuild the compiler once you've changed any configuration options. 
+You will need to rebuild the compiler once you've changed any configuration options.
 
 ## `-Z` flags
 
@@ -38,7 +38,7 @@ normal Rust programs.  IIRC backtraces **don't work** on MinGW,
 sorry. If you have trouble or the backtraces are full of `unknown`,
 you might want to find some way to use Linux, Mac, or MSVC on Windows.
 
-In the default configuration (without `debug` set to `true`), you don't have line numbers 
+In the default configuration (without `debug` set to `true`), you don't have line numbers
 enabled, so the backtrace looks like this:
 
 ```text
@@ -58,7 +58,7 @@ stack backtrace:
   37: rustc_driver::run_compiler
 ```
 
-If you set `debug = true`, you will get line numbers for the stack trace. 
+If you set `debug = true`, you will get line numbers for the stack trace.
 Then the backtrace will look like this:
 
 ```text

src/compiler-src.md

@@ -7,7 +7,7 @@
 > top-level directory has separate directories for the compiler, build-system,
 > std libs, etc, rather than one huge `src/` directory.
 >
-> As of this writing, the std libs have been moved to `library/` and the crates
+> As of January 2021, the std libs have been moved to `library/` and the crates
 > that make up the `rustc` compiler itself have been moved to `compiler/`
 
 Now that we have [seen what the compiler does](./overview.md), let's take a

src/mir/index.md

@@ -230,7 +230,7 @@ but [you can read about those below](#promoted)).
 - **Statements** are represented by the type [`Statement`].
 - **Terminators** are represented by the [`Terminator`].
 - **Locals** are represented by a [newtype'd] index type [`Local`].
-  The data for a local variable is found in the 
+  The data for a local variable is found in the
   [`Body::local_decls`][localdecls] vector). There is also a special constant
   [`RETURN_PLACE`] identifying the special "local" representing the return value.
 - **Places** are identified by the enum [`Place`]. There are a few

src/queries/query-evaluation-model-in-detail.md

@@ -1,5 +1,3 @@
-
-
 # The Query Evaluation Model in Detail
 
 <!-- toc -->

src/stabilization_guide.md

@@ -2,7 +2,7 @@
 
 Once an unstable feature has been well-tested with no outstanding
 concern, anyone may push for its stabilization. It involves the
-following steps.
+following steps:
 
 <!-- toc -->
 

src/traits/goals-and-clauses.md

@@ -198,7 +198,7 @@ it is okay to assume `FromEnv(T: Clone)` in the `loud_clone` example is that we
 _also_ verify `WellFormed(T: Clone)` for each call site of `loud_clone`.
 Similarly, it is okay to assume `FromEnv(HashSet<K>)` in the `loud_insert`
 example because we will verify `WellFormed(HashSet<K>)` for each call site of
-`loud_insert`. 
+`loud_insert`.
 
 #### Outlives(Type: Region), Outlives(Region: Region)
 e.g. `Outlives(&'a str: 'b)`, `Outlives('a: 'static)`

src/ty.md

@@ -191,7 +191,7 @@ There are many variants on the `TyKind` enum, which you can see by looking at it
 - [**Array**][kindarray] Corresponds to `[T; n]`.
 - [**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T`.
 - [**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some
-  associated parts, like `Ty<'tcx>` which is the type that the reference references. 
+  associated parts, like `Ty<'tcx>` which is the type that the reference references.
   `Region<'tcx>` is the lifetime or region of the reference and `Mutability` if the reference
   is mutable or not.
 - [**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec<T>`).