auto merge of #14357 : huonw/rust/spelling, r=pnkfelix

The span on a inner doc-comment would point to the next token, e.g. the span for the `a` line points to the `b` line, and the span of `b` points to the `fn`.

```rust
//! a
//! b

fn bar() {}
```

Author: bors

src/libcollections/hashmap.rs

@@ -659,7 +659,7 @@ static INITIAL_LOAD_FACTOR: Fraction = (9, 10);
 /// on creation by default, this means the ordering of the keys is
 /// randomized, but makes the tables more resistant to
 /// denial-of-service attacks (Hash DoS). This behaviour can be
-/// overriden with one of the constructors.
+/// overridden with one of the constructors.
 ///
 /// It is required that the keys implement the `Eq` and `Hash` traits, although
 /// this can frequently be achieved by using `#[deriving(Eq, Hash)]`.

src/libcore/cell.rs

@@ -8,7 +8,7 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
-//! Sharable mutable containers.
+//! Shareable mutable containers.
 //!
 //! Values of the `Cell` and `RefCell` types may be mutated through
 //! shared references (i.e. the common `&T` type), whereas most Rust
@@ -41,7 +41,7 @@
 //! preventing crash bugs. Because of that, inherited mutability is
 //! preferred, and interior mutability is something of a last
 //! resort. Since cell types enable mutation where it would otherwise
-//! be disallowed though, there are occassions when interior
+//! be disallowed though, there are occasions when interior
 //! mutability might be appropriate, or even *must* be used, e.g.
 //!
 //! * Introducing inherited mutability roots to shared types.

src/libcore/fmt/mod.rs

@@ -76,7 +76,7 @@ pub trait FormatWriter {
     /// This function will return an instance of `FormatError` on error.
     fn write(&mut self, bytes: &[u8]) -> Result;
 
-    /// Glue for usage of the `write!` macro with implementors of this trait.
+    /// Glue for usage of the `write!` macro with implementers of this trait.
     ///
     /// This method should generally not be invoked manually, but rather through
     /// the `write!` macro itself.

src/libcore/iter.rs

@@ -872,10 +872,12 @@ pub trait OrdIterator<A> {
     /// `min_max` finds the minimum and maximum elements in the iterator.
     ///
     /// The return type `MinMaxResult` is an enum of three variants:
+    ///
     /// - `NoElements` if the iterator is empty.
     /// - `OneElement(x)` if the iterator has exactly one element.
-    /// - `MinMax(x, y)` is returned otherwise, where `x <= y`. Two values are equal if and only if
-    /// there is more than one element in the iterator and all elements are equal.
+    /// - `MinMax(x, y)` is returned otherwise, where `x <= y`. Two
+    ///    values are equal if and only if there is more than one
+    ///    element in the iterator and all elements are equal.
     ///
     /// On an iterator of length `n`, `min_max` does `1.5 * n` comparisons,
     /// and so faster than calling `min` and `max separately which does `2 * n` comparisons.

src/libcore/kinds.rs

@@ -266,7 +266,7 @@ pub mod marker {
     #[deriving(Eq,Clone)]
     pub struct NoCopy;
 
-    /// A type which is considered "not sharable", meaning that
+    /// A type which is considered "not shareable", meaning that
     /// its contents are not threadsafe, hence they cannot be
     /// shared between tasks.
     #[lang="no_share_bound"]

src/libcore/result.rs

@@ -260,7 +260,7 @@
 //! The suitability of `fail!` as an error handling mechanism is
 //! limited by Rust's lack of any way to "catch" and resume execution
 //! from a thrown exception. Therefore using failure for error
-//! handling requires encapsulating fallable code in a task. Calling
+//! handling requires encapsulating fallible code in a task. Calling
 //! the `fail!` macro, or invoking `fail!` indirectly should be
 //! avoided as an error reporting strategy. Failure is only for
 //! unrecoverable errors and a failing task is typically the sign of

src/libgetopts/lib.rs

@@ -190,7 +190,7 @@ pub enum Fail_ {
     UnrecognizedOption(StrBuf),
     /// A required option is not present.
     OptionMissing(StrBuf),
-    /// A single occurence option is being used multiple times.
+    /// A single occurrence option is being used multiple times.
     OptionDuplicated(StrBuf),
     /// There's an argument being passed to a non-argument option.
     UnexpectedArgument(StrBuf),

src/libgraphviz/lib.rs

@@ -395,7 +395,7 @@ pub trait Labeller<'a,N,E> {
     fn graph_id(&'a self) -> Id<'a>;
 
     /// Maps `n` to a unique identifier with respect to `self`. The
-    /// implementor is responsible for ensuring that the returned name
+    /// implementer is responsible for ensuring that the returned name
     /// is a valid DOT identifier.
     fn node_id(&'a self, n: &N) -> Id<'a>;
 
@@ -457,7 +457,7 @@ pub type Edges<'a,E> = MaybeOwnedVector<'a,E>;
 /// that is bound by the self lifetime `'a`.
 ///
 /// The `nodes` and `edges` method each return instantiations of
-/// `MaybeOwnedVector` to leave implementors the freedom to create
+/// `MaybeOwnedVector` to leave implementers the freedom to create
 /// entirely new vectors or to pass back slices into internally owned
 /// vectors.
 pub trait GraphWalk<'a, N, E> {

src/libgraphviz/maybe_owned_vec.rs

@@ -31,7 +31,7 @@ use std::slice;
 /// Some clients will have a pre-allocated vector ready to hand off in
 /// a slice; others will want to create the set on the fly and hand
 /// off ownership, via either `Growable` or `FixedLen` depending on
-/// which kind of vector they have constucted.  (The `FixedLen`
+/// which kind of vector they have constructed.  (The `FixedLen`
 /// variant is provided for interoperability with `std::slice` methods
 /// that return `~[T]`.)
 pub enum MaybeOwnedVector<'a,T> {

src/libgreen/lib.rs

@@ -125,7 +125,7 @@
 //! }
 //! ```
 //!
-//! > **Note**: This `main` funciton in this example does *not* have I/O
+//! > **Note**: This `main` function in this example does *not* have I/O
 //! >           support. The basic event loop does not provide any support
 //!
 //! # Starting with I/O support in libgreen