Fix typos in RFCs 2251-2500

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

text/2397-do-not-recommend.md

@@ -20,8 +20,8 @@ When a type fails to implement a trait, Rust has the wonderful behavior of
 looking at possible *other* trait impls which might cause the trait in question
 to be implemented. This is usually a good thing. For example, when using Diesel,
 this is why instead of telling you `SelectStatement<{30 page long type}>:
-ExecuteDsl is not satisifed`, it tells you `posts::id:
-SelectableExpression<users::table> is not satisifed`.
+ExecuteDsl is not satisfied`, it tells you `posts::id:
+SelectableExpression<users::table> is not satisfied`.
 
 However, there are times where this behavior actually makes the resulting error
 more confusing. There are specific trait impls which almost always cause these

text/2438-deny-integer-literal-overflow-lint.md

@@ -31,7 +31,7 @@ Neither I nor anyone else that I have polled can come up with any useful purpose
 
 Given that the upcoming 2018 edition allows us to change existing lints to deny-by-default, now is the ideal time to rectify this accident of history.
 
-One further note: our intent here is primarily to deny overflowing integer literals, though the `overflowing_literals` lint has one other function: to warn when a floating-point literal exceeds the largest or smallest finite number that is representable by the chosen precision. However, this isn't "overflow" per se, because in this case Rust will assign the value of positive or negative infinity to the variable in question. Because this wouldn't clash with our general stance against implicit overflow, it would not be inconsistent to continue allowing this; however, we adopt the stance that it is both desirable to force someone who wants a value of infinity to explicity use e.g. `std::f32::INFINITY`, and that it is unlikely that code in the wild would break because of this (and any potential breakage would be precisely noted by the compiler, and could be fixed quickly and trivially). Therefore we are content with the additional strictness that denying this lint would imply.
+One further note: our intent here is primarily to deny overflowing integer literals, though the `overflowing_literals` lint has one other function: to warn when a floating-point literal exceeds the largest or smallest finite number that is representable by the chosen precision. However, this isn't "overflow" per se, because in this case Rust will assign the value of positive or negative infinity to the variable in question. Because this wouldn't clash with our general stance against implicit overflow, it would not be inconsistent to continue allowing this; however, we adopt the stance that it is both desirable to force someone who wants a value of infinity to explicitly use e.g. `std::f32::INFINITY`, and that it is unlikely that code in the wild would break because of this (and any potential breakage would be precisely noted by the compiler, and could be fixed quickly and trivially). Therefore we are content with the additional strictness that denying this lint would imply.
 
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation

text/2451-re-rebalancing-coherence.md

@@ -285,7 +285,7 @@ applies to `std`, `Vec<T>` now applies to types from `std` and any other crate.
   `impl<T> SomeTrait<LocalType, T> for ForeignType`, because no sibling crate
   can write an overlapping impl. However, this is not something that the
   majority of library authors are aware of, and requires API designers to order
-  their type parameters based on how likely they are to be overidden by other
+  their type parameters based on how likely they are to be overridden by other
   crates.
 
   We could instead provide a mechanism for traits to opt into a redesigned

text/2457-non-ascii-idents.md

@@ -122,7 +122,7 @@ For reference, a list of all the code points allowed by this lint can be found [
 There are some specific interesting code points that we feel necessary to call out here:
 
  - `less_used_codepoints` will warn on U+200C ZERO WIDTH NON-JOINER and U+200D ZERO WIDTH JOINER, despite these being useful in the  Perso-Arabic and some Indic scripts. In Indic scripts these characters force different visual forms, which is not very necessary for programming. These have further semantic meaning in Arabic where they can be used to mark prefixes or mixed-script words, which will not crop up so often in programming (we're not able to use `-` in identifiers for marking pre/suffixes in Latin-script identifiers and it's fine). Persian seems to make the most use of these, with some compound words requiring use of these. For now this RFC does not attempt to deal with this and follows the recommendation of the specification, if there is a need for it in the future we can add this for Persian users.
- - `less_used_codepoints` will not warn about U+02BB MODIFIER LETTER TURNED COMMA or U+02BC MODIFIER LETTER APOSTROPHE. These look somewhat like punctuation relevant to Rust's syntax, so they're a bit tricky. However, these code points are important in Ukranian, Hawaiian, and a bunch of other languages (U+02BB is considered a full-fledged letter in Hawaiian). For now this RFC follows the recommendation of the specification and allows these, however we can change this in the future. The hope is that syntax highlighting is enough to deal with confusions caused by such characters.
+ - `less_used_codepoints` will not warn about U+02BB MODIFIER LETTER TURNED COMMA or U+02BC MODIFIER LETTER APOSTROPHE. These look somewhat like punctuation relevant to Rust's syntax, so they're a bit tricky. However, these code points are important in Ukrainian, Hawaiian, and a bunch of other languages (U+02BB is considered a full-fledged letter in Hawaiian). For now this RFC follows the recommendation of the specification and allows these, however we can change this in the future. The hope is that syntax highlighting is enough to deal with confusions caused by such characters.
 
 
 ## Adjustments to the "bad style" lints
@@ -152,7 +152,7 @@ We expect most of these to be between Cyrillic-Latin-Greek and some in Ethiopic-
 
 In a code base, if the _only_ code points from a given script group (aside from `Latin`, `Common`, and `Inherited`) are such exact confusables, lint about it with `mixed_script_confusables` (lint name can be finalized later).
 
-As an implementation note, it may be worth dealing with confusable modifiers via a separate lint check -- if a modifier is from a different (non-`Common`/`Inherited`) script group from the thing preceding it. This has some behaviorial differences but should not increase the chance of false positives.
+As an implementation note, it may be worth dealing with confusable modifiers via a separate lint check -- if a modifier is from a different (non-`Common`/`Inherited`) script group from the thing preceding it. This has some behavioral differences but should not increase the chance of false positives.
 
 The exception for `Latin` is made because the standard library is Latin-script. It could potentially be removed since a code base using the standard library (or any Latin-using library) is likely to be using enough of it that there will be non-confusable characters in use. (This is in unresolved questions)
 

text/2471-lint-test-inner-function.md

@@ -11,7 +11,7 @@ Add a lint that warns when marking an inner function as `#[test]`.
 # Motivation
 [motivation]: #motivation
 
-`#[test]` is used to mark funcitons to be run as part of a test suite. The
+`#[test]` is used to mark functions to be run as part of a test suite. The
 functions being marked need to be addressable for this to work. Currently,
 marking an inner function as `#[test]` will not raise any errors or warnings,
 but the test will silently not be run. By adding a lint that identifies these

text/2476-clippy-uno.md

@@ -39,7 +39,7 @@ one is an indication of a very specialized situation.
 
 Currently to allow/deny Clippy lints you have to `#[cfg_attr(clippy, allow(lintname))]` which is somewhat tedious.
 
-The compiler should support something like `#[allow(clippy::lintname)]` which won't attempt to warn about nonexistant lints
+The compiler should support something like `#[allow(clippy::lintname)]` which won't attempt to warn about nonexistent lints
 at all when not running Clippy.
 
 
@@ -513,7 +513,7 @@ concisely.
 false }`
 (or vice versa) and suggest using the condition directly.
 - [misrefactored_assign_op](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#misrefactored_assign_op): Checks for `a op= a op b` or `a op= b op a` patterns.
-- [neg_cmp_op_on_partial_ord](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#neg_cmp_op_on_partial_ord): Checks for the usage of negated comparision operators on types which only implement
+- [neg_cmp_op_on_partial_ord](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#neg_cmp_op_on_partial_ord): Checks for the usage of negated comparison operators on types which only implement
 `PartialOrd` (e.g. `f64`).
 - [zero_prefixed_literal](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#zero_prefixed_literal): Warns if an integral constant literal starts with `0`.
 - [bool_comparison](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#bool_comparison): Checks for expressions of the form `x == true` (or vice
@@ -530,7 +530,7 @@ or closure that returns the unit type.
 - [clone_on_copy](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#clone_on_copy): Checks for usage of `.clone()` on a `Copy` type.
 - [unit_arg](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#unit_arg): Checks for passing a unit value as an argument to a function without using a unit literal (`()`).
 - [transmute_int_to_float](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#transmute_int_to_float): Checks for transmutes from an integer to a float.
-- [double_comparisons](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#double_comparisons): Checks for double comparions that could be simpified to a single expression.
+- [double_comparisons](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#double_comparisons): Checks for double comparisons that could be simplified to a single expression.
 - [eval_order_dependence](https://rust-lang-nursery.github.io/rust-clippy/master/index.html#eval_order_dependence): Checks for a read and a write to the same variable where
 whether the read occurs before or after the write depends on the evaluation
 order of sub-expressions.

text/2480-liballoc.md

@@ -46,7 +46,7 @@ toward making `no_std` application compatible with Stable Rust.
 As of this writing not all of that work is completed yet.
 For example, [`#[panic_implementation]`][panic-impl] is required for `no_std` but still unstable.
 So it may seem that this RFC does not unlock anything new,
-as `no_std` application still need to be on Nigthly anyway.
+as `no_std` application still need to be on Nightly anyway.
 
 [coordinated push]: https://github.com/rust-lang-nursery/embedded-wg/issues/42
 [panic-impl]: https://github.com/rust-lang/rust/issues/44489

text/2497-if-let-chains.md

@@ -997,7 +997,7 @@ is a more general *control flow graph* ([CFG]) control feature.
 While it doesn't as straightforwardly solve the rightward drift or ergonomic
 issues as this RFC does, it allows [the macros to be improved] by removing
 duplication of `else` blocks. The closest syntax today for that is `loop-break`,
-but that doesn't work as `continue` is intentionally non-hygenic.
+but that doesn't work as `continue` is intentionally non-hygienic.
 
 RFC 2046 is also a bit orthogonal in the sense that it's fully compatible
 with this RFC. The general label break is useful and powerful, as seen in