Fix typos in non-RFCs

Author: jhpratt

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 => {