auto merge of #13640 : jbcrail/rust/spelling-updates, r=alexcrichton

src/doc/complement-cheatsheet.md

@@ -29,7 +29,7 @@ let x: int = 42;
 let y: ~str = format!("{:t}", x);   // binary
 let y: ~str = format!("{:o}", x);   // octal
 let y: ~str = format!("{:x}", x);   // lowercase hexadecimal
-let y: ~str = format!("{:X}", x);   // uppercase hexidecimal
+let y: ~str = format!("{:X}", x);   // uppercase hexadecimal
 ~~~
 
 **String to int, in non-base-10**

src/doc/guide-ffi.md

@@ -337,7 +337,7 @@ Besides classical synchronization mechanisms like mutexes, one possibility in
 Rust is to use channels (in `std::comm`) to forward data from the C thread
 that invoked the callback into a Rust task.
 
-If an asychronous callback targets a special object in the Rust address space
+If an asynchronous callback targets a special object in the Rust address space
 it is also absolutely necessary that no more callbacks are performed by the
 C library after the respective Rust object gets destroyed.
 This can be achieved by unregistering the callback in the object's

src/doc/intro.md

@@ -226,7 +226,7 @@ Now here's the exciting part:
 because `numbers` is an owned type,
 when it is sent across the channel,
 it is actually *moved*,
-transfering ownership of `numbers` between tasks.
+transferring ownership of `numbers` between tasks.
 This ownership transfer is *very fast* -
 in this case simply copying a pointer -
 while also ensuring that the original owning task cannot create data races by continuing to read or write to `numbers` in parallel with the new owner.
@@ -318,7 +318,7 @@ fn main() {
 This is almost exactly the same,
 except that this time `numbers` is first put into an `Arc`.
 `Arc::new` creates the `Arc`,
-`.clone()` makes another `Arc` that referrs to the same contents.
+`.clone()` makes another `Arc` that refers to the same contents.
 So we clone the `Arc` for each task,
 send that clone down the channel,
 and then use it to print out a number.

src/doc/rust.md

@@ -295,7 +295,7 @@ Raw string literals do not process any escapes. They start with the character
 `U+0022` (double-quote) character. The _raw string body_ is not defined in the
 EBNF grammar above: it can contain any sequence of Unicode characters and is
 terminated only by another `U+0022` (double-quote) character, followed by the
-same number of `U+0023` (`#`) characters that preceeded the opening `U+0022`
+same number of `U+0023` (`#`) characters that preceded the opening `U+0022`
 (double-quote) character.
 
 All Unicode characters contained in the raw string body represent themselves,
@@ -2256,7 +2256,7 @@ fn main() {
 Certain aspects of Rust may be implemented in the compiler, but they're not
 necessarily ready for every-day use. These features are often of "prototype
 quality" or "almost production ready", but may not be stable enough to be
-considered a full-fleged language feature.
+considered a full-fledged language feature.
 
 For this reason, Rust recognizes a special crate-level attribute of the form:
 
@@ -4005,7 +4005,7 @@ dependencies will be used:
    could only be found in an `rlib` format. Remember that `staticlib` formats
    are always ignored by `rustc` for crate-linking purposes.
 
-2. If a static library is being produced, all upstream dependecies are
+2. If a static library is being produced, all upstream dependencies are
    required to be available in `rlib` formats. This requirement stems from the
    same reasons that a dynamic library must have all dynamic dependencies.
 

src/libstd/fmt/num.rs

@@ -74,11 +74,11 @@ struct Octal;
 #[deriving(Clone, Eq)]
 struct Decimal;
 
-/// A hexidecimal (base 16) radix, formatted with lower-case characters
+/// A hexadecimal (base 16) radix, formatted with lower-case characters
 #[deriving(Clone, Eq)]
 struct LowerHex;
 
-/// A hexidecimal (base 16) radix, formatted with upper-case characters
+/// A hexadecimal (base 16) radix, formatted with upper-case characters
 #[deriving(Clone, Eq)]
 pub struct UpperHex;