Fix typos

src/autodiff/installation.md

@@ -1,6 +1,6 @@
 # Installation
 
-In the near future, `std::autodiff` should become available in nightly builds for users. As a contribute however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you succesfully build this project on a tier2/tier3 target.
+In the near future, `std::autodiff` should become available in nightly builds for users. As a contributor however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you successfully build this project on a tier2/tier3 target.
 
 ## Build instructions
 

src/rustdoc-internals/rustdoc-test-suite.md

@@ -16,10 +16,10 @@ In addition to the directives listed here,
 `rustdoc` tests also support most
 [compiletest directives](../tests/directives.html).
 
-All `PATH`s in directives are relative to the the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`),
+All `PATH`s in directives are relative to the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`),
 so it is conventional to use a `#![crate_name = "foo"]` attribute to avoid
 having to write a long crate name multiple times.
-To avoid repetion, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument.
+To avoid repetition, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument.
 
 All arguments take the form of quoted strings
 (both single and double quotes are supported),
@@ -87,7 +87,7 @@ compiletest's `--bless` flag is forwarded to htmldocck.
 
 Usage: `//@ has-dir PATH`
 
-Checks for the existance of directory `PATH`.
+Checks for the existence of directory `PATH`.
 
 ### `files`
 
@@ -106,7 +106,7 @@ Example: `//@ files "foo/bar" '["index.html", "sidebar-items.js"]'`
 ## Limitations
 `htmldocck.py` uses the xpath implementation from the standard library.
 This leads to several limitations:
-* All `XPATH` arguments must start with `//` due to a flaw in the implemention.
+* All `XPATH` arguments must start with `//` due to a flaw in the implementation.
 * Many XPath features (functions, axies, etc.) are not supported.
 * Only well-formed HTML can be parsed (hopefully rustdoc doesn't output mismatched tags).
 

src/type-checking.md

@@ -17,7 +17,7 @@ Type "collection" is the process of converting the types found in the HIR
 **internal representation** used by the compiler (`Ty<'tcx>`) – we also do
 similar conversions for where-clauses and other bits of the function signature.
 
-To try and get a sense for the difference, consider this function:
+To try and get a sense of the difference, consider this function:
 
 ```rust,ignore
 struct Foo { }

src/type-inference.md

@@ -19,7 +19,7 @@ Here, the type of `things` is *inferred* to be `Vec<&str>` because of the value
 we push into `things`.
 
 The type inference is based on the standard Hindley-Milner (HM) type inference
-algorithm, but extended in various way to accommodate subtyping, region
+algorithm, but extended in various ways to accommodate subtyping, region
 inference, and higher-ranked types.
 
 ## A note on terminology

src/typing_parameter_envs.md

@@ -4,7 +4,7 @@
 
 ## Typing Environments
 
-When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The the set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively).
+When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively).
 
 When an environment to perform type system operations in has not yet been created, the [`TypingEnv`][tenv] can be used to bundle all of the external context required into a single type.
 
@@ -13,11 +13,11 @@ Once a context to perform type system operations in has been created (e.g. an [`
 [ocx]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/struct.ObligationCtxt.html
 [fnctxt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/fn_ctxt/struct.FnCtxt.html
 
-## Parameter Environemnts
+## Parameter Environments
 
 ### What is a `ParamEnv`
 
-The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead are implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds.
+The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds.
 
 In most cases `ParamEnv`s are initially created via the [`param_env` query][query] which returns a `ParamEnv` derived from the provided item's where clauses. A `ParamEnv` can also be created with arbitrary sets of clauses that are not derived from a specific item, such as in [`compare_method_predicate_entailment`][method_pred_entailment] where we create a hybrid `ParamEnv` consisting of the impl's where clauses and the trait definition's function's where clauses.
 
@@ -73,7 +73,7 @@ fn foo2<T>(a: T) {
 
 ### Acquiring a `ParamEnv`
 
-Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroing when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs.
+Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroring when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs.
 
 In the large majority of cases, when a `ParamEnv` is required it either already exists somewhere in scope, or above in the call stack and should be passed down. A non exhaustive list of places where you might find an existing `ParamEnv`:
 - During typeck `FnCtxt` has a [`param_env` field][fnctxt_param_env]