Fix typos in RFCs 1-250

Author: jhpratt

text/0019-opt-in-builtin-traits.md

@@ -71,8 +71,8 @@ opt-in. There are two main reasons for my concern:
 
 To elaborate on those two points: With respect to parallelization: for
 the most part, Rust types are threadsafe "by default". To make
-something non-threadsafe, you must employ unsychronized interior
-mutability (e.g., `Cell`, `RefCell`) or unsychronized shared ownership
+something non-threadsafe, you must employ unsynchronized interior
+mutability (e.g., `Cell`, `RefCell`) or unsynchronized shared ownership
 (`Rc`). In both cases, there are also synchronized variants available
 (`Mutex`, `Arc`, etc). This implies that we can make APIs to enable
 intra-task parallelism and they will work ubiquitously, so long as
@@ -116,7 +116,7 @@ All three of these (`Snapshot`, `NoManaged`, `NoDrop`) can be easily
 defined using traits with default impls.
 
 A final, somewhat weaker, motivator is aesthetics. Ownership has allowed
-us to move threading almost entirely into libaries. The one exception
+us to move threading almost entirely into libraries. The one exception
 is that the `Send` and `Share` types remain built-in. Opt-in traits
 makes them *less* built-in, but still requires custom logic in the
 "impl matching" code as well as special safety checks when

text/0040-libstd-facade.md

@@ -164,7 +164,7 @@ algorithms apart from the default sorting algorithm.
 #### FromStr
 
 This trait and module are left out because strings are left out. All types in
-libmini can have their implemention of FromStr in the crate which implements
+libmini can have their implementation of FromStr in the crate which implements
 strings
 
 #### Floats

text/0048-traits.md

@@ -231,7 +231,7 @@ Note that there is some interaction with the distinction between input
 and output type parameters discussed in the previous
 example. Specifically, we must never *infer* the value of the `Self`
 type parameter based on the impls in scope. This is because it would
-cause *crate concatentation* to potentially lead to compilation errors
+cause *crate concatenation* to potentially lead to compilation errors
 in the form of inference failure.
 
 ## Properties
@@ -242,7 +242,7 @@ There are important properties I would like to guarantee:
   values for all of its type parameters, there should always be at
   most one applicable impl. This should remain true even when unknown,
   additional crates are loaded.
-- **Crate concatentation:** It should always be possible to take two
+- **Crate concatenation:** It should always be possible to take two
   creates and combine them without causing compilation errors. This
   property
 

text/0155-anonymous-impl-only-in-same-module.md

@@ -101,7 +101,7 @@ and methods of a struct should be defined nearby.
 I propose three changes to the language:
 
 - `impl` on multiple-ident paths such as `impl mymod::MyStruct` is disallowed.
-  Since this currently suprises the user by having absolutely no effect for
+  Since this currently surprises the user by having absolutely no effect for
   static methods, support for this is already broken.
 - `impl MyStruct` must occur in the same module that `MyStruct` is defined.
   This is to prevent the above problems with `impl`-across-modules.

text/0169-use-path-as-id.md

@@ -5,7 +5,7 @@
 # Summary
 
 Change the rebinding syntax from `use ID = PATH` to `use PATH as ID`,
-so that paths all line up on the left side, and imported identifers
+so that paths all line up on the left side, and imported identifiers
 are all on the right side.  Also modify `extern crate` syntax
 analogously, for consistency.
 

text/0194-cfg-syntax.md

@@ -85,7 +85,7 @@ proposed names read better with the function-like syntax and are consistent
 with `Iterator::all` and `Iterator::any`.
 
 Issue [#2119](https://github.com/rust-lang/rust/issues/2119) proposed the
-addition of `||` and `&&` operators and parantheses to the attribute syntax
+addition of `||` and `&&` operators and parentheses to the attribute syntax
 to result in something like `#[cfg(a || (b && c)]`. I don't favor this proposal
 since it would result in a major change to the attribute syntax for relatively
 little readability gain.

text/0195-associated-items.md

@@ -1263,7 +1263,7 @@ impl<'a, T> Sliceable for &'a Vec<T> {
 But then there's a difficult question:
 
 ```
-fn dice<A>(a: &A) -> &A::Slice where &A: Slicable {
+fn dice<A>(a: &A) -> &A::Slice where &A: Sliceable {
     a // is this allowed?
 }
 ```

text/0218-empty-struct-with-braces.md

@@ -98,7 +98,7 @@ completed, one can then take the next step of adding the actual field.
 # Drawbacks
 
 Some people like "There is only one way to do it."  But, there is
-precendent in Rust for violating "one way to do it" in favor of
+precedent in Rust for violating "one way to do it" in favor of
 syntactic convenience or regularity; see
 the [Precedent for flexible syntax in Rust] appendix.
 Also, see the [Always Require Braces] alternative below.
@@ -311,7 +311,7 @@ adoption of [Rust RFC 25].
 
 ## Precedent for flexible syntax in Rust
 
-There is precendent in Rust for violating "one way to do it" in favor
+There is precedent in Rust for violating "one way to do it" in favor
 of syntactic convenience or regularity.
 
 For example, one can often include an optional trailing comma, for
@@ -358,7 +358,7 @@ is not a democracy, the number of commenters should not matter anyway.)
 * "Frequently start out with an empty struct and add fields as I need them." ==> Favors: This RFC or Always Require Braces
 * "Foo{} suggests is constructing something that it's not; all uses of the value `Foo` are indistinguishable from each other" ==> Favors: Status Quo
 * "I find it strange anyone would prefer `let x = Foo{};` over `let x = Foo;`" ==> Favors Status Quo; strongly opposes Always Require Braces.
-* "I agree that 'instantiation-should-follow-declation', that is, structs declared `;, (), {}` should only be instantiated [via] `;, (), { }` respectively" ==> Opposes leniency of this RFC in that it allows expression to use include or omit `{}` on an empty struct, regardless of declaration form, and vice-versa.
+* "I agree that 'instantiation-should-follow-declaration', that is, structs declared `;, (), {}` should only be instantiated [via] `;, (), { }` respectively" ==> Opposes leniency of this RFC in that it allows expression to use include or omit `{}` on an empty struct, regardless of declaration form, and vice-versa.
 * "The code generation argument is reasonable, but I wouldn't want to force noisier syntax on all 'normal' code just to make macros work better." ==> Favors: This RFC
 
 [Always Require Braces]: #always-require-braces