fix some typos

src/borrow_check/opaque-types-region-inference-restrictions.md

@@ -102,7 +102,7 @@ fn good() -> Opaque<'static> {}
 **Motivation:** an attempt to implement the uniqueness restriction for RPITs resulted in a
 [breakage found by crater]( https://github.com/rust-lang/rust/pull/112842#issuecomment-1610057887).
 This can be mitigated by this exception to the rule.
-An example of the the code that would otherwise break:
+An example of the code that would otherwise break:
 ```rust
 struct Type<'a>(&'a ());
 impl<'a> Type<'a> {
@@ -224,7 +224,7 @@ fn test::{closure#0}(_upvar: &'?8 str) -> Opaque<'?6, '?7> {
 // But in the parent fn it is known that `'?6: '?8`.
 //
 // When encountering an opaque definition `Opaque<'?6, '?7> := &'8 str`,
-// The member constraints algotithm does not know enough to safely make `?8 = '?6`.
+// The member constraints algorithm does not know enough to safely make `?8 = '?6`.
 // For this reason, it errors with a sensible message:
 // "hidden type captures lifetime that does not appear in bounds".
 ```
@@ -235,7 +235,7 @@ in closures.
 
 **Output types:**
 I believe the most common scenario where this causes issues in real-world code is with
-closure/async-block output types. It is worth noting that there is a discrepancy betweeen closures
+closure/async-block output types. It is worth noting that there is a discrepancy between closures
 and async blocks that further demonstrates this issue and is attributed to the
 [hack of `replace_opaque_types_with_inference_vars`][source-replace-opaques],
 which is applied to futures only.

src/building/bootstrapping/what-bootstrapping-does.md

@@ -358,7 +358,7 @@ to use it.
 Finally, `MAGIC_EXTRA_RUSTFLAGS` bypasses the `cargo` cache to pass flags to rustc without
 recompiling all dependencies.
 
-`RUSTDOCFLAGS`, `RUSTDOCFLAGS_BOOTSTRAP`, and `RUSTDOCFLAGS_NOT_BOOTSTRAP` are anologous to
+`RUSTDOCFLAGS`, `RUSTDOCFLAGS_BOOTSTRAP`, and `RUSTDOCFLAGS_NOT_BOOTSTRAP` are analogous to
 `RUSTFLAGS`, but for rustdoc.
 
 `CARGOFLAGS` will pass arguments to cargo itself (e.g. `--timings`). `CARGOFLAGS_BOOTSTRAP` and

src/building/quickstart.md

@@ -46,7 +46,7 @@ rustc +stage1 testfile.rs
 After doing a change, you can run the compiler test suite with `./x test`.
 
 `./x test` runs the full test suite, which is slow and rarely what you want.
-Usually, `./x test tests/ui` is what you want after a comiler change,
+Usually, `./x test tests/ui` is what you want after a compiler change,
 testing all [UI tests](../tests/ui.md) that invoke the compiler on a specific test file and check the output.
 
 ```sh

src/overview.md

@@ -284,7 +284,7 @@ queries are cached on disk so that the compiler can tell which queries' results
 changed from the last compilation and only redo those. This is how incremental
 compilation works.
 
-In principle, for the query-fied steps, we do each of the above for each item
+In principle, for the query-field steps, we do each of the above for each item
 individually. For example, we will take the `HIR` for a function and use queries
 to ask for the `LLVM-IR` for that HIR. This drives the generation of optimized
 `MIR`, which drives the borrow checker, which drives the generation of `MIR`, and
@@ -303,11 +303,11 @@ to remain to ensure that unreachable functions still have their errors emitted.
 [passes]: https://github.com/rust-lang/rust/blob/e69c7306e2be08939d95f14229e3f96566fb206c/compiler/rustc_interface/src/passes.rs#L791
 
 Moreover, the compiler wasn't originally built to use a query system; the query
-system has been retrofitted into the compiler, so parts of it are not query-fied
+system has been retrofitted into the compiler, so parts of it are not query-field
 yet. Also, LLVM isn't our code, so that isn't querified either. The plan is to
 eventually query-fy all of the steps listed in the previous section,
 but as of <!-- date-check --> November 2022, only the steps between `HIR` and
-`LLVM-IR` are query-fied. That is, lexing, parsing, name resolution, and macro
+`LLVM-IR` are query-field. That is, lexing, parsing, name resolution, and macro
 expansion are done all at once for the whole program.
 
 One other thing to mention here is the all-important "typing context",

src/return-position-impl-trait-in-trait.md

@@ -119,7 +119,7 @@ conceptually inherits most of its information from the parent function
 (e.g. `visibility`), or because it's trivially knowable because it's an
 associated type (`opt_def_kind`).
 
-Some other queries are more involved, or cannot be feeded, and we
+Some other queries are more involved, or cannot be fed, and we
 document the interesting ones of those below:
 
 ##### `generics_of` for the trait

src/walkthrough.md

@@ -195,7 +195,7 @@ some requested changes. When you finished iterating on the changes, you can mark
 Feel free to ask questions or discuss things you don't understand or disagree with. However,
 recognize that the PR won't be merged unless someone on the Rust team approves
 it. If a reviewer leave a comment like `r=me after fixing ...`, that means they approve the PR and 
-you can merge it with comment with `@bors r=reviwer-github-id`(e.g. `@bors r=eddyb`) to merge it 
+you can merge it with comment with `@bors r=reviewer-github-id`(e.g. `@bors r=eddyb`) to merge it 
 after fixing trivial issues. Note that `r=someone` requires permission and bors could say 
 something like "🔑 Insufficient privileges..." when commenting `r=someone`. In that case, 
 you have to ask the reviewer to revisit your PR.