Merge pull request #3238 from cuishuang/master

ehuss · web-flow · commit ef664dd71830 · 2022-03-04T10:43:10.000-08:00
fix some typos
diff --git a/text/0048-traits.md b/text/0048-traits.md
@@ -219,7 +219,7 @@ wait till the end then we will have more type information available.
 
 In my proposed solution, we eliminate the phase distinction. Instead,
 we simply track *pending constraints*. We are free to attempt to
-resolve pending constraints whenever desired. In paricular, whenever
+resolve pending constraints whenever desired. In particular, whenever
 we find we need more type information to proceed with some
 type-overloaded operation, rather than reporting an error we can try
 and resolve pending constraints. If that helps give more information,
diff --git a/text/0198-slice-notation.md b/text/0198-slice-notation.md
@@ -222,6 +222,6 @@ There are at least two downsides to doing so, however:
 * The idea of `Vec` as a smart pointer around a slice, and the use of `&*v` as
   above, is somewhat counterintuitive, especially for such a basic type.
 
-Ultimately, notation for slicing seems desireable on its own merits anyway, and
+Ultimately, notation for slicing seems desirable on its own merits anyway, and
 if it can eliminate the need to implement `Deref` for `Vec` and `String`, all
 the better.
diff --git a/text/0213-defaulted-type-params.md b/text/0213-defaulted-type-params.md
@@ -555,7 +555,7 @@ way (mechanical default outside of fn body, inference within).
 An alternative design is to use the `K=V` notation proposed in the
 associated items RFC for specify the values of default type
 parameters. However, this is somewhat odd, because default type
-parameters appear in a positional list, and thus it is suprising that
+parameters appear in a positional list, and thus it is surprising that
 values for the non-defaulted parameters are given positionally, but
 values for the defaulted type parameters are given with labels.
 
diff --git a/text/0216-collection-views.md b/text/0216-collection-views.md
@@ -123,7 +123,7 @@ is when you're *not sure* if you need to insert, in which case you should be pre
 Otherwise, `find_mut` is likely sufficient.
 
 The result is actually an enum, that will either be Occupied or Vacant. These two variants correspond
-to concrete types for when the key matched something in the map, and when the key didn't, repsectively.
+to concrete types for when the key matched something in the map, and when the key didn't, respectively.
 
 If there isn't a match, the user has exactly one option: insert a value using `set`, which will also insert
 the guarantor, and destroy the Entry. This is to avoid the costs of maintaining the structure, which
diff --git a/text/0403-cargo-build-command.md b/text/0403-cargo-build-command.md
@@ -413,7 +413,7 @@ would look like with respect to its set of C dependencies.
 
 ## Case study: generated code
 
-As the release of Rust 1.0 comes closer, the use of complier plugins has become
+As the release of Rust 1.0 comes closer, the use of compiler plugins has become
 increasingly worrying over time. It is likely that plugins will not be available
 by default in the stable and beta release channels of Rust. Many core Cargo
 packages in the ecosystem today, such as gl-rs and iron, depend on plugins
diff --git a/text/0507-release-channels.md b/text/0507-release-channels.md
@@ -290,7 +290,7 @@ is added in addition to the existing `staged_stable` attribute, as
 well recording the version in which the deprecation was performed with
 the `since` parameter.
 
-(Occassionally unstable APIs may be deprecated for the sake of easing
+(Occasionally unstable APIs may be deprecated for the sake of easing
 user transitions, in which case they receive both the `staged_stable`
 and `staged_deprecated` attributes at once.)
 
diff --git a/text/0528-string-patterns.md b/text/0528-string-patterns.md
@@ -315,7 +315,7 @@ without a lifetime parameter by making use of higher kinded types in order to si
 string APIs. Eg, instead of `fn starts_with<'a, P>(&'a self, pat: P) -> bool where P: Pattern<'a>;`
 you'd have `fn starts_with<P>(&self, pat: P) -> bool where P: Pattern;`.
 
-In order to not break backwards-compability, these can use the same generic-impl trick to
+In order to not break backwards-compatibility, these can use the same generic-impl trick to
 forward to the old traits, which would roughly look like this:
 
 ```rust
diff --git a/text/0550-macro-future-proofing.md b/text/0550-macro-future-proofing.md
@@ -183,7 +183,7 @@ ensures that a legal macro definition will continue to assign the same
 determination as to where `... tt` ends and `uu ...` begins, even as
 new syntactic forms are added to the language.
 
-The second part says that a separated complex NT must use a seperator
+The second part says that a separated complex NT must use a separator
 token that is part of the predetermined follow set for the internal
 contents of the NT. This ensures that a legal macro definition will
 continue to parse an input fragment into the same delimited sequence
@@ -318,9 +318,9 @@ NT could be empty (i.e. ε ∈ FIRST(interior)). (I overlooked this fact
 in my first round of prototyping.)
 
 NOTE: The above definition for LAST assumes that we keep our
-pre-existing rule that the seperator token in a complex NT is *solely* for
+pre-existing rule that the separator token in a complex NT is *solely* for
 separating elements; i.e. that such NT's do not match fragments that
-*end with* the seperator token. If we choose to lift this restriction
+*end with* the separator token. If we choose to lift this restriction
 in the future, the above definition will need to be revised
 accordingly.
 
diff --git a/text/0587-fn-return-should-be-an-associated-type.md b/text/0587-fn-return-should-be-an-associated-type.md
@@ -179,6 +179,6 @@ type variable).
 
 We could make `FnMut()` desugar to `FnMut<()>`, and hence require an
 explicit `FnMut() -> ()` to bind the return type to unit.  This feels
-suprising and inconsistent.
+surprising and inconsistent.
 
 
diff --git a/text/0592-c-str-deref.md b/text/0592-c-str-deref.md
@@ -43,7 +43,7 @@ for representing borrowed C string data, since:
    to FFI functions without an intermediate allocation in `CString`.
 
 As a pattern of owned/borrowed type pairs has been established
-thoughout other modules (see e.g.
+throughout other modules (see e.g.
 [path reform](https://github.com/rust-lang/rfcs/pull/474)),
 it makes sense that `CString` gets its own borrowed counterpart.
 
diff --git a/text/0599-default-object-bound.md b/text/0599-default-object-bound.md
@@ -111,7 +111,7 @@ expressions, they only include cover those cases where an explicit
 lifetime bound was required today. In function signatures, lifetime
 bounds can always be omitted, and it is impossible to distinguish
 `&SomeTrait` from `&SomeStruct` using only a regular
-expression. However, we belive that the proposed rule would be
+expression. However, we believe that the proposed rule would be
 compatible with the existing defaults for function signatures in all
 or virtually all cases.
 
diff --git a/text/0640-debug-improvements.md b/text/0640-debug-improvements.md
@@ -18,7 +18,7 @@ to implement `Debug` manually.
 
 The conventions for `Debug` format state that output should resemble Rust
 struct syntax, without added line breaks. This can make output difficult to
-read in the presense of complex and deeply nested structures:
+read in the presence of complex and deeply nested structures:
 ```rust
 HashMap { "foo": ComplexType { thing: Some(BufferedReader { reader: FileStream { path: "/home/sfackler/rust/README.md", mode: R }, buffer: 1013/65536 }), other_thing: 100 }, "bar": ComplexType { thing: Some(BufferedReader { reader: FileStream { path: "/tmp/foobar", mode: R }, buffer: 0/65536 }), other_thing: 0 } }
 ```
diff --git a/text/0771-std-iter-once.md b/text/0771-std-iter-once.md
@@ -40,7 +40,7 @@ These wrapper structs exist to allow future backwards-compatible changes, and hi
 
 # Drawbacks
 
-Although a tiny amount of code, it still does come with a testing, maintainance, etc. cost.
+Although a tiny amount of code, it still does come with a testing, maintenance, etc. cost.
 
 It's already possible to do this via `Some(x).into_iter()`, `std::iter::repeat(x).take(1)` (for `x: Clone`), `vec![x].into_iter()`, various contraptions involving `iterate`...
 
diff --git a/text/0809-box-and-in-for-stdlib.md b/text/0809-box-and-in-for-stdlib.md
@@ -383,7 +383,7 @@ pub trait Place<Data: ?Sized> {
 /// intermediate values (e.g. the return value of `Vec::emplace_back`)
 /// or `Copy`, since the `make_place` method takes `self` by value.
 pub trait Placer<Data: ?Sized> {
-    /// `Place` is the intermedate agent guarding the
+    /// `Place` is the intermediate agent guarding the
     /// uninitialized state for `Data`.
     type Place: InPlace<Data>;
 
diff --git a/text/2795-format-args-implicit-identifiers.md b/text/2795-format-args-implicit-identifiers.md
@@ -146,14 +146,14 @@ The following are motivations why this RFC argues this case:
       4 |     println!(concat!("hello {person}"));
         |              ^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
 
-* The expression may expand to a format string which contains new identifiers not written by the users, bypassing macro hygiene in suprising ways. For example, if the `concat!` macro did not have the hygiene issue described above, it could be to "splice together" an implicit named argument like so:
+* The expression may expand to a format string which contains new identifiers not written by the users, bypassing macro hygiene in surprising ways. For example, if the `concat!` macro did not have the hygiene issue described above, it could be to "splice together" an implicit named argument like so:
 
        let person = "Charlie";
        println!(concat!("hello {p", "er", "son", "}"));
 
    The RFC author argues that it appears highly undesirable that implicit capture of the `person` identifier should occur in this example given above.
 
-* Using the hygienic context of the format string for implicit named arguments can have potentially suprising results even just with `macro_rules!` macros.
+* Using the hygienic context of the format string for implicit named arguments can have potentially surprising results even just with `macro_rules!` macros.
 
   For example, the RFC author found that with a proof-of-concept implementation of implicit named arguments the invocation below would print `"Snoopy"`:
 
