fix some more typos

12 files changed, 16 insertions, 16 deletions

diff --git a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md
index 3521c00f5cf..0f81d3cb48a 100644
--- a/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md
+++ b/src/doc/rustc-dev-guide/src/backend/backend-agnostic.md
@@ -45,7 +45,7 @@ heavily on other parts of the crate. The separation of the code must not affect
 the logic of the code nor its performance.
 
 For these reasons, the separation process involves two transformations that
-have to be done at the same time for the resulting code to compile :
+have to be done at the same time for the resulting code to compile:
 
 1. replace all the LLVM-specific types by generics inside function signatures
    and structure definitions;
diff --git a/src/doc/rustc-dev-guide/src/closure.md b/src/doc/rustc-dev-guide/src/closure.md
index 718a0e5d78b..427919cd579 100644
--- a/src/doc/rustc-dev-guide/src/closure.md
+++ b/src/doc/rustc-dev-guide/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
diff --git a/src/doc/rustc-dev-guide/src/const-eval.md b/src/doc/rustc-dev-guide/src/const-eval.md
index ee0269601af..69329a3e085 100644
--- a/src/doc/rustc-dev-guide/src/const-eval.md
+++ b/src/doc/rustc-dev-guide/src/const-eval.md
@@ -17,7 +17,7 @@ Prominent examples are:
     * need to be known to check for overlapping patterns
 
 Additionally constant evaluation can be used to reduce the workload or binary
-size at runtime by precomputing complex operations at compiletime and only
+size at runtime by precomputing complex operations at compile time and only
 storing the result.
 
 All uses of constant evaluation can either be categorized as "influencing the type system"
diff --git a/src/doc/rustc-dev-guide/src/diagnostics.md b/src/doc/rustc-dev-guide/src/diagnostics.md
index ccd1011659d..709e9d4f889 100644
--- a/src/doc/rustc-dev-guide/src/diagnostics.md
+++ b/src/doc/rustc-dev-guide/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.
diff --git a/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md b/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md
index c56d51a4bb7..bdf4e4cd870 100644
--- a/src/doc/rustc-dev-guide/src/opaque-types-impl-trait-inference.md
+++ b/src/doc/rustc-dev-guide/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
 
diff --git a/src/doc/rustc-dev-guide/src/solve/caching.md b/src/doc/rustc-dev-guide/src/solve/caching.md
index 72b90c59bee..e568d47ca25 100644
--- a/src/doc/rustc-dev-guide/src/solve/caching.md
+++ b/src/doc/rustc-dev-guide/src/solve/caching.md
@@ -98,8 +98,8 @@ 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
-availabledepth `n`, then their result should be the same for any depths smaller than `n`.
+[^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.
 
 [chapter on coinduction]: ./coinduction.md
diff --git a/src/doc/rustc-dev-guide/src/solve/invariants.md b/src/doc/rustc-dev-guide/src/solve/invariants.md
index c16a3aeb2b3..588da490a44 100644
--- a/src/doc/rustc-dev-guide/src/solve/invariants.md
+++ b/src/doc/rustc-dev-guide/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:
diff --git a/src/doc/rustc-dev-guide/src/solve/the-solver.md b/src/doc/rustc-dev-guide/src/solve/the-solver.md
index f7d82d117a0..006fb649d22 100644
--- a/src/doc/rustc-dev-guide/src/solve/the-solver.md
+++ b/src/doc/rustc-dev-guide/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.
 
diff --git a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md
index 911553ad3df..63b09a43f47 100644
--- a/src/doc/rustc-dev-guide/src/traits/implied-bounds.md
+++ b/src/doc/rustc-dev-guide/src/traits/implied-bounds.md
@@ -41,7 +41,7 @@ requirements of impls and functions as explicit predicates.
 
 These bounds are not added to the `ParamEnv` of the affected item itself. For lexical
 region resolution they are added using [`fn OutlivesEnvironment::with_bounds`].
-Similarly,during MIR borrowck we add them using
+Similarly, during MIR borrowck we add them using
 [`fn UniversalRegionRelationsBuilder::add_implied_bounds`].
 
 [We add implied bounds for the function signature and impl header in MIR borrowck][mir].
@@ -81,4 +81,4 @@ This results in multiple unsoundnesses:
 
 [#25860]: https://github.com/rust-lang/rust/issues/25860
 [#84591]: https://github.com/rust-lang/rust/issues/84591
-[#100051]: https://github.com/rust-lang/rust/issues/100051
\ No newline at end of file
+[#100051]: https://github.com/rust-lang/rust/issues/100051
diff --git a/src/doc/rustc-dev-guide/src/ty_module/binders.md b/src/doc/rustc-dev-guide/src/ty_module/binders.md
index 6f31103d7f3..defb7cde514 100644
--- a/src/doc/rustc-dev-guide/src/ty_module/binders.md
+++ b/src/doc/rustc-dev-guide/src/ty_module/binders.md
@@ -16,7 +16,7 @@ Usages of these parameters is represented by the `RegionKind::Bound` (or `TyKind
 - A [`BoundVar`] which specifies which of the parameters the `Binder` introduces we are referring to.
 - We also sometimes store some extra information for diagnostics reasons via the [`BoundTyKind`]/[`BoundRegionKind`] but this is not important for type equality or more generally the semantics of `Ty`. (omitted from the above example)
 
-In debug output (and also informally when talking to eachother) we tend to write these bound variables in the format of `^DebruijnIndex_BoundVar`. The above example would instead be written as `Binder(fn(&'^0_0), &[BoundVariableKind::Region])`. Sometimes when the `DebruijnIndex` is `0` we just omit it and would write `^0`.
+In debug output (and also informally when talking to each other) we tend to write these bound variables in the format of `^DebruijnIndex_BoundVar`. The above example would instead be written as `Binder(fn(&'^0_0), &[BoundVariableKind::Region])`. Sometimes when the `DebruijnIndex` is `0` we just omit it and would write `^0`.
 
 Another concrete example, this time a mixture of `for<'a>` in a where clause and a type:
 ```
diff --git a/src/doc/rustc-dev-guide/src/ty_module/early_binder.md b/src/doc/rustc-dev-guide/src/ty_module/early_binder.md
index e8ff3a53078..d83d73c955b 100644
--- a/src/doc/rustc-dev-guide/src/ty_module/early_binder.md
+++ b/src/doc/rustc-dev-guide/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. 
 
diff --git a/src/doc/rustc-dev-guide/src/ty_module/param_ty_const_regions.md b/src/doc/rustc-dev-guide/src/ty_module/param_ty_const_regions.md
index e6dfe8a6684..c52f0c0df2a 100644
--- a/src/doc/rustc-dev-guide/src/ty_module/param_ty_const_regions.md
+++ b/src/doc/rustc-dev-guide/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>`.