fix some more typos

src/closure.md

@@ -157,7 +157,7 @@ The other option is to step through the code using lldb or gdb.
 
 1. `rust-lldb build/host/stage1/bin/rustc test.rs`
 2. In lldb:
-    1. `b upvar.rs:134`  // Setting the breakpoint on a certain line in the upvar.rs file`
+    1. `b upvar.rs:134`  // Setting the breakpoint on a certain line in the upvar.rs file
     2. `r`  // Run the program until it hits the breakpoint
 
 Let's start with [`upvar.rs`][upvar]. This file has something called

src/diagnostics.md

@@ -111,7 +111,7 @@ Here are a few examples:
   their crate, making this a hard error would make refactoring and development
   very painful.
 - [future-incompatible lints]:
-  these are silencable lints.
+  these are silenceable lints.
   It was decided that making them fixed errors would cause too much breakage,
   so warnings are instead emitted,
   and will eventually be turned into fixed (hard) errors.

src/opaque-types-impl-trait-inference.md

@@ -78,7 +78,7 @@ If that fails, we reveal the hidden type of the opaque type,
 but only to prove this specific trait bound, not in general.
 Revealing is done by invoking the `type_of` query on the `DefId` of the opaque type.
 The query will internally request the hidden types from the defining function(s)
-and return that (see [the section on `type_of`](#Within-the-type_of-query) for more details).
+and return that (see [the section on `type_of`](#within-the-type_of-query) for more details).
 
 #### Flowchart of type checking steps
 

src/solve/caching.md

@@ -98,7 +98,7 @@ TODO: write this :3
 [req-depth-ck]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L76-L86
 [update-depth]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_trait_selection/src/solve/search_graph.rs#L308
 [rem-depth]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L124
-[^1]: This is overly restrictive: if all nested goal return the overflow response with some
+[^1]: This is overly restrictive: if all nested goals return the overflow response with some
 available depth `n`, then their result should be the same for any depths smaller than `n`.
 We can implement this optimization in the future.
 

src/solve/invariants.md

@@ -33,7 +33,7 @@ inference variables in both the lhs and rhs, the now potentially structurally di
 types should still be equal to each other.
 
 Needed to prevent goals from succeeding in HIR typeck and then failing in MIR borrowck.
-If this does invariant is broken MIR typeck ends up failing with an ICE.
+If this invariant is broken MIR typeck ends up failing with an ICE.
 
 ### Applying inference results from a goal does not change its result ❌
 
@@ -91,7 +91,7 @@ it can easily result in unsoundness, e.g. [#57893](https://github.com/rust-lang/
 
 If a trait goal holds with an empty environment, there should be a unique `impl`,
 either user-defined or builtin, which is used to prove that goal. This is
-necessary to select a unique method. It 
+necessary to select a unique method.
 
 We do however break this invariant in few cases, some of which are due to bugs,
 some by design:

src/solve/the-solver.md

@@ -25,7 +25,7 @@ a separate "probe", to not leak inference constraints to the other candidates.
 We then try to merge the assembled candidates via `EvalCtxt::merge_candidates`.
 
 
-## Important concepts and design pattern
+## Important concepts and design patterns
 
 ### `EvalCtxt::add_goal`
 
@@ -64,7 +64,7 @@ eagerly instantiates `'a` with a placeholder and then recursively proves
 Some goals can be proven in multiple ways. In these cases we try each option in
 a separate "probe" and then attempt to merge the resulting responses by using
 `EvalCtxt::try_merge_responses`. If merging the responses fails, we use
-`EvalCtxt::flounder` instead, returning ambiguity. For some goals, we try
+`EvalCtxt::flounder` instead, returning ambiguity. For some goals, we try to
 incompletely prefer some choices over others in case `EvalCtxt::try_merge_responses`
 fails.
 

src/ty_module/early_binder.md

@@ -48,7 +48,7 @@ fn bar(foo: Foo<u32, f32>) {
 In the compiler the `instantiate` call for this is done in [`FieldDef::ty`] ([src][field_def_ty_src]), at some point during type checking `bar` we will wind up calling `FieldDef::ty(x, &[u32, f32])` in order to obtain the type of `foo.x`.
 
 **Note on indices:** It is a bug if the index of a `Param` does not match what the `EarlyBinder` binds. For
-example, if the index is out of bounds or the index index of a lifetime corresponds to a type parameter.
+example, if the index is out of bounds or the index of a lifetime corresponds to a type parameter.
 These sorts of errors are caught earlier in the compiler during name resolution where we disallow references
 to generics parameters introduced by items that should not be nameable by the inner item. 
 

src/ty_module/param_ty_const_regions.md

@@ -53,7 +53,7 @@ Concretely given the `ty::Generics` for the item the parameter is defined on, if
 
 The index fully defines the `Ty` and is the only part of `TyKind::Param` that matters for reasoning about the code we are compiling. 
 
-Generally we do not care what the name is and only use the index is included for diagnostics and debug logs as otherwise it would be
+Generally we do not care what the name is and only use the index. The name is included for diagnostics and debug logs as otherwise it would be
 incredibly difficult to understand the output, i.e. `Vec<Param(0)>: Sized` vs `Vec<T>: Sized`. In debug output, parameter types are
 often printed out as `{name}/#{index}`, for example in the function `foo` if we were to debug print `Vec<T>` it would be written as `Vec<T/#0>`.