Merge pull request #2209 from rmehri01/typos

Author: jieyouxu

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;

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/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"

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,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

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/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
+[#100051]: https://github.com/rust-lang/rust/issues/100051

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:
 ```