Merge pull request #3277 from jhpratt/fix-typos

Fix typos

Author: ehuss

compiler_changes.md

@@ -28,7 +28,7 @@ submitted later if there is scope for large changes to the language RFC.
 * Adding, removing, or changing a stable compiler flag
 * The implementation of new language features where there is significant change
   or addition to the compiler. There is obviously some room for interpretation
-  about what consitutes a "significant" change and how much detail the
+  about what constitutes a "significant" change and how much detail the
   implementation RFC needs. For guidance, [associated items](text/0195-associated-items.md)
   and [UFCS](text/0132-ufcs.md) would clearly need an implementation RFC,
   [type ascription](text/0803-type-ascription.md) and
@@ -41,7 +41,7 @@ submitted later if there is scope for large changes to the language RFC.
 
 * Bug fixes, improved error messages, etc.
 * Minor refactoring/tidying up
-* Implmenting language features which have an accepted RFC, where the
+* Implementing language features which have an accepted RFC, where the
   implementation does not significantly change the compiler or require
   significant new design work
 * Adding unstable API for tools (note that all compiler API is currently unstable)

libs_changes.md

@@ -76,7 +76,7 @@ as `std` has become more conservative in favour of the much more agile cargovers
     * Too marginal for std
     * Significant implementation problems
 
-* A PR may also be closed because an RFC is approriate.
+* A PR may also be closed because an RFC is appropriate.
 
 * A (non-RFC) PR  may be **merged as unstable**. In this case, the feature
 should have a fresh feature gate and an associated tracking issue for

style-guide/expressions.md

@@ -643,7 +643,7 @@ Examples:
 ```rust
 match foo {
     foo => bar,
-    a_very_long_patten | another_pattern if an_expression() => {
+    a_very_long_pattern | another_pattern if an_expression() => {
         no_room_for_this_expression()
     }
     foo => {

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?
 }
 ```