Typo fixes.

1 files changed, 9 insertions, 9 deletions

diff --git a/src/doc/rustdoc.md b/src/doc/rustdoc.md
index 3359cd4f40d..5d41f297e7d 100644
--- a/src/doc/rustdoc.md
+++ b/src/doc/rustdoc.md
@@ -43,7 +43,7 @@ pub fn recalibrate() {
 Doc comments are markdown, and are currently parsed with the
 [sundown][sundown] library. rustdoc does not yet do any fanciness such as
 referencing other items inline, like javadoc's `@see`. One exception to this
-is that the first paragrah will be used as the "summary" of an item in the
+is that the first paragraph will be used as the "summary" of an item in the
 generated documentation:
 
 ~~~
@@ -79,11 +79,11 @@ rustdoc can also generate JSON, for consumption by other tools, with
 
 # Using the Documentation
 
-The web pages generated by rustdoc present the same logical heirarchy that one
+The web pages generated by rustdoc present the same logical hierarchy that one
 writes a library with. Every kind of item (function, struct, etc) has its own
 color, and one can always click on a colored type to jump to its
 documentation. There is a search bar at the top, which is powered by some
-javascript and a statically-generated search index. No special web server is
+JavaScript and a statically-generated search index. No special web server is
 required for the search.
 
 [sundown]: https://github.com/vmg/sundown/
@@ -108,7 +108,7 @@ code, the `ignore` string can be added to the three-backtick form of markdown
 code block.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```
     // This is a testable code block
@@ -126,7 +126,7 @@ You can specify that the test's execution should fail with the `should_fail`
 directive.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```should_fail
     // This code block is expected to generate a failure when run
@@ -138,7 +138,7 @@ You can specify that the code block should be compiled but not run with the
 `no_run` directive.
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```no_run
     // This code will be compiled but not executed
@@ -153,7 +153,7 @@ testing the code block (NB. the space after the `#` is required, so
 that one can still write things like `#[deriving(Eq)]`).
 
     /**
-    # nested codefences confuse sundown => indentation + comment to
+    # nested code fences confuse sundown => indentation + comment to
     #  avoid failing tests
     ```rust
     # /!\ The three following lines are comments, which are usually stripped off by
@@ -162,7 +162,7 @@ that one can still write things like `#[deriving(Eq)]`).
     # these first five lines but a non breakable one.
     #
     # // showing 'fib' in this documentation would just be tedious and detracts from
-    # // what's actualy being documented.
+    # // what's actually being documented.
     # fn fib(n: int) { n + 2 }
 
     do spawn { fib(200); }
@@ -190,7 +190,7 @@ $ rustdoc --test lib.rs --test-args '--help'
 ~~~
 
 When testing a library, code examples will often show how functions are used,
-and this code often requires `use`-ing paths from the crate. To accomodate this,
+and this code often requires `use`-ing paths from the crate. To accommodate this,
 rustdoc will implicitly add `extern crate <crate>;` where `<crate>` is the name of
 the crate being tested to the top of each code example. This means that rustdoc
 must be able to find a compiled version of the library crate being tested. Extra