Fix typos in RFCs 2251-2500

Author: jhpratt

text/2296-option-replace.md

@@ -13,7 +13,7 @@ This RFC proposes the addition of `Option::replace` to complete the `Option::tak
 
 You can see the `Option` as a container and other containers already have this kind of method to change a value in-place like the [HashMap::replace](https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.replace) method.
 
-How do you replace a value inside an `Option`, you can use `mem::replace` but it can be really unconvenient to import the `mem` module just for that. Why not adding a useful method to do that ?
+How do you replace a value inside an `Option`, you can use `mem::replace` but it can be really inconvenient to import the `mem` module just for that. Why not adding a useful method to do that ?
 
 This is the symmetry of the already present `Option::take` method.
 

text/2298-macro-at-most-once-rep.md

@@ -90,7 +90,7 @@ The pattern portion is composed of zero or more subpatterns concatenated togethe
 ```rust
 macro_rules! println {
   // Takes a variable number of arguments after the template
-  ($tempate:expr, $($args:expr),*) => { ... }
+  ($template:expr, $($args:expr),*) => { ... }
 }
 ```
 which can be invoked like so:
@@ -103,7 +103,7 @@ println!("", foo, bar) // 2 args
 
 The `*` in the pattern of this example indicates "0 or more repetitions". One can also use `+` for "at _least_ one repetition" or `?` for "at _most_ one repetition".
 
-In the body of a rule, one can specify to repeat some code for every occurence of the pattern in the invokation:
+In the body of a rule, one can specify to repeat some code for every occurrence of the pattern in the invocation:
 
 ```rust
 macro_rules! foo {

text/2306-convert-id.md

@@ -84,7 +84,7 @@ With `identity`, this intent becomes clearer.
 
 The `drop` function in `core::mem` is defined as `pub fn drop<T>(_x: T) { }`.
 The same effect can be achieved by writing `{ _x; }`. This presents us
-with a precendent that such trivial functions are considered useful and
+with a precedent that such trivial functions are considered useful and
 includable inside the standard library even though they can be written easily
 inside a user's crate.
 

text/2307-concrete-nonzero-types.md

@@ -62,7 +62,7 @@ With `NonNull` covering pointers, the remaining use cases for `NonZero` are inte
 One problem of the current API is that
 it is unclear what happens or what *should* happen to `NonZero<T>` or `Option<NonZero<T>>`
 when `T` is some type other than a raw pointer or a primitive integer.
-In particular, crates outside of `std` can implement `Zeroable` for their abitrary types
+In particular, crates outside of `std` can implement `Zeroable` for their arbitrary types
 since it is a public trait.
 
 To avoid this question entirely,
@@ -77,7 +77,7 @@ When an integer value can never be zero because of the way an algorithm works,
 this fact can be encoded in the type system
 by using for example the `NonZeroU32` type instead of `u32`.
 
-This enables code recieving such a value to safely make some assuptions,
+This enables code receiving such a value to safely make some assumptions,
 for example that dividing by this value will not cause a `attempt to divide by zero` panic.
 This may also enable the compiler to make some memory optimizations,
 for example `Option<NonZeroU32>` might take no more space than `u32`
@@ -182,7 +182,7 @@ This adds to the ever-expanding API surface of the standard library.
   (Stable APIs that mention traits like `RangeArgument` that are not stable *yet*
   but have a path to stabilization are less of an abuse.)
 
-* Still, we could decide on some answer to “`Zeroable` for abitrary types”,
+* Still, we could decide on some answer to “`Zeroable` for arbitrary types”,
   implement and test it, stabilize `NonZero<T>` and `Zeroable` as-is
   (re-exported in `std`), and not add `num::NonZero*`.
 

text/2314-roadmap-2018.md

@@ -123,7 +123,7 @@ Finally, there are several highly-awaited features that are **unlikely to ship**
 #### Compiler
 
 
-> [Give me non-embarassing compilation speed!](https://matthewkmayer.github.io/blag/public/post/rust-2018/) (@matthewkmayer)
+> [Give me non-embarrassing compilation speed!](https://matthewkmayer.github.io/blag/public/post/rust-2018/) (@matthewkmayer)
 
 Compiler work will center on:
 

text/2325-stable-simd.md

@@ -449,10 +449,10 @@ on x86 platforms:
 Infrastructure-wise the contents of `std::arch` are expected to continue to be
 defined in the [`stdsimd` crate/repository][stdsimd]. Intrinsics defined here go
 through a rigorous test suite involving automatic verification against the
-upstream architecture defintion, verification that the correct instruction is
+upstream architecture definition, verification that the correct instruction is
 generated by LLVM, and at least one runtime test for each intrinsic to ensure it
 not only compiles but also produces correct results. It's expected that
-stabilized intrinsics will meet these critera to the best of their ability.
+stabilized intrinsics will meet these criteria to the best of their ability.
 
 Currently today on x86 and ARM platforms the stdsimd crate performs all these
 checks, but these checks are not yet implemented for PowerPC/MIPS/etc, but
@@ -579,7 +579,7 @@ desire to stabilize MMX intrinsics, the `__m64` and all related intrinsics
 This RFC represents a *significant* addition to the standard library, maybe one
 of the largest we've ever done! As a result alternate implementations of Rust
 will likely have a difficult time catching up to rustc/LLVM with all the SIMD
-intrinsics. Additionaly the semantics of "packed SIMD types should work
+intrinsics. Additionally the semantics of "packed SIMD types should work
 everywhere" may be overly difficult to implement in alternate implementations.
 It is worth noting that both [Cranelift][cranelift] and GCC support packed SIMD
 types.
@@ -713,7 +713,7 @@ being.
 
 Despite the CI infrastructure of the `stdsimd` crate it seems inevitable that
 we'll get an intrinsic wrong at some point. What do we do in a situation like
-that? This situation is somewhat analagous to the `libc` crate but there you can
+that? This situation is somewhat analogous to the `libc` crate but there you can
 fix the problem downstream (just have a corrected type/definition) for
 vendor intrinsics it's not so easy.
 

text/2333-prior-art.md

@@ -132,8 +132,8 @@ this was a bad idea, we can always revert back to the way it was before.
 
 Finally, a longer template risks making it harder to contribute to the
 RFC process as an author as you are expected to fill in more sections.
-Some people who don't know a lot of other langauges may be intimidated into
-thinking that they are expected to know a wide variety of langauges and that
+Some people who don't know a lot of other languages may be intimidated into
+thinking that they are expected to know a wide variety of languages and that
 their contribution is not welcome otherwise. This drawback can be mitigated
 by more clearly communicating that the RFC process is a collaborative effort.
 If an author does not have prior art to offer up right away, other participants

text/2351-is-sorted.md

@@ -210,7 +210,7 @@ too.
 
 
 ### Add the three methods to additional data structures (like `LinkedList`) as well
-Adding these methods to every data structure in the standard libary is a lot of
+Adding these methods to every data structure in the standard library is a lot of
 duplicate code. Optimally, we would have a trait that represents sequential
 data structures and would only add `is_sorted` and friends to said trait. We
 don't have such a trait as of now; so `Iterator` is the next best thing. Slices

text/2383-lint-reasons.md

@@ -50,7 +50,7 @@ This supports the use cases of projects, teams, or organizations using specific
 sets of code style guidelines beyond the Rust defaults. This also enables the
 creation and maintenance of documented practices and preferences that can be
 standardized in a useful way. Furthermore, this provides a standardized means of
-explaining decisions when a style gude must be violated by attaching an
+explaining decisions when a style guide must be violated by attaching an
 overriding lint attribute to a specific item.
 
 - What is the expected outcome?

text/2388-try-expr.md

@@ -295,7 +295,7 @@ any exceptions in the `try { .. }` block.
 
 An alternative would be to simply use the `do catch { ... }` syntax we have
 in the nightly compiler. However, this syntax was not in the accepted `catch`
-RFC and was only a temporarly fix around `catch { .. }` not working.
+RFC and was only a temporary fix around `catch { .. }` not working.
 
 ## Alternative: `do try { .. }`
 
@@ -488,10 +488,10 @@ problematic as it:
 
 Arguably, this candidate keyword is a somewhat a good choice.
 
-To `trap` an error is sufficently clear on the "exception boundary" semantics
+To `trap` an error is sufficiently clear on the "exception boundary" semantics
 we wish to communicate.
 
-However, `trap` is used as an error handler in at least one langauge.
+However, `trap` is used as an error handler in at least one language.
 
 It also does not have the familiarity that `try` does have and is entirely
 inconsistent wrt. naming in the standard library.
@@ -907,7 +907,7 @@ part and not for the handler, these languages are:
 + [Erlang](http://erlang.org/doc/reference_manual/expressions.html#catch)
 + [Tcl](https://www.tcl.tk/man/tcl/TclCmd/catch.htm)
 
-However, the combined popularity of these langauges are not significant as
+However, the combined popularity of these languages are not significant as
 compared to that for `try { .. }`.
 
 # Unresolved questions