Fix typos in RFCs 2001-2250

Author: jhpratt

text/2025-nested-method-calls.md

@@ -340,7 +340,7 @@ to cover at some point in works like this:
   complicated method calls that are not covered by this proposal, such
   as the `v[0].push_str(&format!("{}", v.len()));` example. In that
   case, a simple desugaring can be used to show why the compiler
-  rejects this code -- in particular, a comparison with the errorneous
+  rejects this code -- in particular, a comparison with the erroneous
   examples may be helpful. A keen observer may note the contrast with
   `vec.push(vec.len())`, but such an observer can be referred to the
   reference. =)
@@ -604,7 +604,7 @@ whether a borrow is activated is affected by "no-ops" like `let x = y`
 
 Therefore, introducing two-phased borrows **outside** of method-call
 desugaring form doesn't feel like the right approach. (But, if they
-are limited to method-call desugaring, as ths RFC proposes, then they
+are limited to method-call desugaring, as this RFC proposes, then they
 are a simple and effective mechanism without broader impact.)
 
 ### Borrowing for the future
@@ -765,7 +765,7 @@ makes the Rust system qualitatively more complex to reason about.
 
 If all this talk of "steps in complexity" seems abstract, I think that
 the most immediate way it will surface is when we try to
-**teach**. Supporting discontinous borrows just makes it that much
+**teach**. Supporting discontinuous borrows just makes it that much
 harder to craft small examples that show how borrowing works. It will
 make the system feel more mysterious, since the underlying rules are
 indeed more complex and thus harder to "intuit" on your own. Getting

text/2045-target-feature.md

@@ -25,7 +25,7 @@ The objective of this RFC is to extend the Rust language to solve these three pr
 
 ## Target features
 
-Each rustc target has a default set of target features that can be controled via
+Each rustc target has a default set of target features that can be controlled via
 the backend compilation options. The target features for each target should
 be documented by the compiler and the backends (e.g. LLVM).
 
@@ -460,13 +460,13 @@ What happens if the macro `cfg!(target_feature = "feature_name")` is used inside
 
 This might result in monomorphization errors if `#![cfg(target_feature)]` is used, but not if `if cfg!(target_feature)` is used since in this case all branches need to type-check properly.
 
-We might want to ammend this RFC with more concrete semantics about this as we improve the compiler.
+We might want to amend this RFC with more concrete semantics about this as we improve the compiler.
 
 ## How do we handle ABI issues with portable vector types?
 
 The ABI of `#[target_feature]` functions does not change for all types currently available in stable Rust. However, there are types that we might want to add to the language at some point, like portable vector types, for which this is not the case.
 
-The behavior of `#[target_feature]` for those types should be specified in the RFC that proposes to stabilize those types, and this RFC should be ammended as necessary.
+The behavior of `#[target_feature]` for those types should be specified in the RFC that proposes to stabilize those types, and this RFC should be amended as necessary.
 
 The following examples showcase some potential problems when calling functions with mismatching ABIs, or when using function pointers.
 

text/2052-epochs.md

@@ -404,7 +404,7 @@ We'll wrap up with the full details of the mechanisms at play.
 [how-we-teach-this]: #how-we-teach-this
 
 First and foremost, if we accept this RFC, we should publicize the plan widely,
-including on the main Rust blog, in a style simlar to [previous posts] about our
+including on the main Rust blog, in a style similar to [previous posts] about our
 release policy. This will require extremely careful messaging, to make clear
 that editions are *not* about breaking Rust code, but instead *primarily*
 about putting together a globally coherent, polished product on a regular basis,

text/2057-refcell-replace.md

@@ -75,7 +75,7 @@ counter.replace(counter.replace(0) - 1);
 ```
 
 Also, we're adding more specific functions to a core type.
-That comes with cost in documentation and maintainance.
+That comes with cost in documentation and maintenance.
 
 # Alternatives
 [alternatives]: #alternatives

text/2089-implied-bounds.md

@@ -655,7 +655,7 @@ impl Set<NotHash> { ... }
 ```
 the error will not be caught until someone actually uses `Set<NotHash>`.
 
-The idea is, when encountering an fn/trait impl/inherent impl, retrieve all input types that appear in the signature / header and for each input type `T`, do the following: retrieve type variables `X1, ..., Xn` bound by the declaration and ask for `∃X1, ..., ∃Xn; WF(T)` in an empty enviromnent (in Chalk terms). If there is no possible substitution for the existentials, output a warning.
+The idea is, when encountering an fn/trait impl/inherent impl, retrieve all input types that appear in the signature / header and for each input type `T`, do the following: retrieve type variables `X1, ..., Xn` bound by the declaration and ask for `∃X1, ..., ∃Xn; WF(T)` in an empty environment (in Chalk terms). If there is no possible substitution for the existentials, output a warning.
 
 Example:
 ```rust
@@ -687,7 +687,7 @@ trait Bar where Self: Foo { }
 // `Self: Foo` holds if `WF(Self: Bar)`
 // `WF(Self: Foo)` holds if `WF(Self: Bar)`
 ```
-Now suppose we are asking wether `u8: Foo` holds. The following branch exists in the proof tree:
+Now suppose we are asking whether `u8: Foo` holds. The following branch exists in the proof tree:
 `u8: Foo` holds if `WF(u8: Bar)` holds if `u8: Foo` holds.
 
 I *think* rustc would have the right behavior currently: just dismiss this branch since it only leads to the tautological rule `(u8: Foo) if (u8: Foo)`.
@@ -705,7 +705,7 @@ In Chalk we have a more sophisticated cycle detection strategy based on tabling,
 
 ## Including parameters in well-formedness rules
 
-Specific to this design: instead of disregarding parameters in well-formedness checks, we could have included them, and added reverse rules of the form: "`WF(T)` holds if `WF(Struct<T>)` holds". From a theoretical point of view, this would have had the same effects as the current design, and would have avoided the whole `InputTypes` thing. However, implementation in Chalk revelead some tricky issues. Writing in Chalk-style, suppose we have rules like:
+Specific to this design: instead of disregarding parameters in well-formedness checks, we could have included them, and added reverse rules of the form: "`WF(T)` holds if `WF(Struct<T>)` holds". From a theoretical point of view, this would have had the same effects as the current design, and would have avoided the whole `InputTypes` thing. However, implementation in Chalk revealed some tricky issues. Writing in Chalk-style, suppose we have rules like:
 ```
 WF(Struct<T>) :- WF(T)
 WF(T) :- WF(Struct<T>)

text/2091-inline-semantic.md

@@ -878,7 +878,7 @@ This RFC tries to abide by the following restrictions:
     accepts the caller information; it shouldn't require the trait itself to enforce it. It
     should not affect the signature of the function. This is an extension of rule 2, since the
     `Index` trait is involved in `HashMap::index`. The stability of `Index` must be upheld, e.g. it
-    should remain object-safe, and existing implementions should not be forced to accept the caller
+    should remain object-safe, and existing implementations should not be forced to accept the caller
     location.
 
 Restriction 4 "interface independence" is currently not implemented due to lack of
@@ -1031,7 +1031,7 @@ extern {
     fn close_fd(fd: c_int);
 }
 
-// declaration + defintion
+// declaration + definition
 #[precondition(option.is_some(), "Trying to unwrap None")]
 fn unwrap<T>(option: Option<T>) -> T {
     match option {

text/2093-infer-outlives.md

@@ -356,10 +356,10 @@ changed to (e.g.) remove the field `vec`, then it may no longer
 require that `T: 'a` holds, and hence `foo()` would no longer have the
 implied bound that `T: 'a` holds.
 
-This situation is considerd unlikely: typically, if a struct has a
+This situation is considered unlikely: typically, if a struct has a
 lifetime parameter (such as the `Iter` struct), then the fact that
 it contains (or may contain) a borrowed reference is rather
-fundamental to how it works. If that borrowed refernce were to be
+fundamental to how it works. If that borrowed reference were to be
 removed entirely, then the struct's API will likely be changing in
 other incompatible ways, since that implies that the struct is now
 taking ownership of data it used to borrow (or else has access to less

text/2094-nll.md

@@ -435,7 +435,7 @@ speak). This can range from a few sequential statements (as in problem
 case #1) to something more complex, such as covering one arm in a
 match but not the others (problem case #2).
 
-However, in order to sucessfully type the full range of examples that
+However, in order to successfully type the full range of examples that
 we would like, we have to go a bit further than just changing
 lifetimes to a portion of the control-flow graph. **We also have to
 take location into account when doing subtyping checks**. This is in
@@ -670,7 +670,7 @@ and the notation `'a` refers to some named lifetime inference variable
 Once the constraints are created, the **inference algorithm** solves
 the constraints. This is done via fixed-point iteration: each
 lifetime variable begins as an empty set and we iterate over the
-constaints, repeatedly growing the lifetimes until they are big enough
+constraints, repeatedly growing the lifetimes until they are big enough
 to satisfy all constraints.
 
 (If you'd like to compare this to the prototype code, the file
@@ -954,7 +954,7 @@ use" (and hence their "locks" still enforced).
 Once the constraints are created, the **inference algorithm** solves
 the constraints. This is done via fixed-point iteration: each
 lifetime variable begins as an empty set and we iterate over the
-constaints, repeatedly growing the lifetimes until they are big enough
+constraints, repeatedly growing the lifetimes until they are big enough
 to satisfy all constraints.
 
 The meaning of a constraint like `('a: 'b) @ P` is that, starting from
@@ -1756,7 +1756,7 @@ U. In general, the approach is to describe the errors in "narrative" form:
 
 - First, value is borrowed occurs.
 - Next, the action occurs, invalidating the reference.
-- Finally, the next use occcurs, after the reference has been invalidated.
+- Finally, the next use occurs, after the reference has been invalidated.
 
 This approach is similar to what we do today, but we often neglect to
 mention this third point, where the next use occurs. Note that the
@@ -2082,7 +2082,7 @@ proposal was `Ref2<'r, 'w>`, in which mutable references change to
 have two distinct lifetimes, a "read" lifetime (`'r`) and a "write"
 lifetime (`'w`), where read encompasses the entire span of the
 reference, but write only contains those points where writes are
-occuring. This RFC does not attempt to change the approach to nested
+occurring. This RFC does not attempt to change the approach to nested
 method calls, rather continuing with the RFC 2025 approach (which
 affects only the borrowck handling). However, if we did wish to adopt
 a `Ref2`-style approach in the future, it could be done backwards

text/2102-unnamed-fields.md

@@ -549,7 +549,7 @@ support references to named structures.
 ## Allowing type parameters
 
 We could allow the type parameters of generic types as the named type of an
-unamed field. This could allow creative flexibility in API design, such as
+unnamed field. This could allow creative flexibility in API design, such as
 having a generic type that adds a field alongside the fields of the type it
 contains. However, this could also lead to much more complex errors that do not
 arise until the point that code references the generic type. Prohibiting the

text/2103-tool-attributes.md

@@ -29,7 +29,7 @@ fn foo() {}
 ```
 
 This would be allowed by the compiler but ignored. When Rustfmt is run on the
-crate, it will read the attibute and skip formatting `foo` (note that we make no
+crate, it will read the attribute and skip formatting `foo` (note that we make no
 provision for reading the attribute or doing anything with it, that is all up to
 the tool).
 
@@ -85,7 +85,7 @@ compiler warning about unused lints. E.g., we want a user to be able to write
 
 This section assumes that attributes (e.g., `#[test]`) have already been taught.
 
-You can use attibutes in your crate to pass information to tools. For now, this
+You can use attributes in your crate to pass information to tools. For now, this
 facility is limited to the tools we include with the Rust distribution.
 
 The names of these attributes are a path starting with the name of a tool, and
@@ -157,7 +157,7 @@ A similar opt-in mechanism will exist for lints.
 ## Proposed for immediate implementation
 
 There is an attribute path white list of the names of tools shipped with the Rust
-distribution. Any crate can use an attibute path starting with those names and
+distribution. Any crate can use an attribute path starting with those names and
 the attribute will not trigger the custom attribute lint or require a macro
 feature gate.
 
@@ -205,10 +205,10 @@ check for unused attributes/lints as part of a possible long-term solution
 without introducing new warnings or errors.
 
 
-### Forward and backward compatability
+### Forward and backward compatibility
 
 Since custom attributes are feature gated and scoped attributes are part of the
-unstable macros 2.0 work, there is no backwards compatability issue.
+unstable macros 2.0 work, there is no backwards compatibility issue.
 
 For tools who want to move to these newly stable attributes (e.g., from
 `rustfmt_skip` to `rustfmt::skip`) they will have to manage the change