Spell check librustc_error_codes

src/librustc_error_codes/error_codes/E0038.md

@@ -136,7 +136,7 @@ type parameters, the number of monomorphized implementations the compiler
 generates does not grow drastically, since the compiler will only generate an
 implementation if the function is called with unparametrized substitutions
 (i.e., substitutions where none of the substituted types are themselves
-parametrized).
+parameterized).
 
 However, with trait objects we have to make a table containing _every_ object
 that implements the trait. Now, if it has type parameters, we need to add

src/librustc_error_codes/error_codes/E0084.md

@@ -20,7 +20,7 @@ enum NightsWatch {
 }
 ```
 
-or you remove the integer represention of your enum:
+or you remove the integer representation of your enum:
 
 ```
 enum NightsWatch {}

src/librustc_error_codes/error_codes/E0307.md

@@ -36,7 +36,7 @@ impl Trait for Foo {
 }
 ```
 
-E0307 will be emitted by the compiler when using an invalid reciver type,
+E0307 will be emitted by the compiler when using an invalid receiver type,
 like in the following example:
 
 ```compile_fail,E0307

src/librustc_error_codes/error_codes/E0373.md

@@ -31,7 +31,7 @@ Since our new thread runs in parallel, the stack frame containing `x` and `y`
 may well have disappeared by the time we try to use them. Even if we call
 `thr.join()` within foo (which blocks until `thr` has completed, ensuring the
 stack frame won't disappear), we will not succeed: the compiler cannot prove
-that this behaviour is safe, and so won't let us do it.
+that this behavior is safe, and so won't let us do it.
 
 The solution to this problem is usually to switch to using a `move` closure.
 This approach moves (or copies, where possible) data into the closure, rather

src/librustc_error_codes/error_codes/E0426.md

@@ -8,7 +8,7 @@ loop {
 }
 ```
 
-Please verify you spelt or declare the label correctly. Example:
+Please verify you spelled or declared the label correctly. Example:
 
 ```
 'a: loop {