@@ -43,7 +43,7 @@ pub fn recalibrate() {
4343Doc comments are markdown, and are currently parsed with the
4444[ sundown] [ sundown ] library. rustdoc does not yet do any fanciness such as
4545referencing other items inline, like javadoc's ` @see ` . One exception to this
46- is that the first paragrah will be used as the "summary" of an item in the
46+ is that the first paragraph will be used as the "summary" of an item in the
4747generated documentation:
4848
4949~~~
@@ -79,11 +79,11 @@ rustdoc can also generate JSON, for consumption by other tools, with
7979
8080# Using the Documentation
8181
82- The web pages generated by rustdoc present the same logical heirarchy that one
82+ The web pages generated by rustdoc present the same logical hierarchy that one
8383writes a library with. Every kind of item (function, struct, etc) has its own
8484color, and one can always click on a colored type to jump to its
8585documentation. There is a search bar at the top, which is powered by some
86- javascript and a statically-generated search index. No special web server is
86+ JavaScript and a statically-generated search index. No special web server is
8787required for the search.
8888
8989[ sundown ] : https://github.com/vmg/sundown/
@@ -108,7 +108,7 @@ code, the `ignore` string can be added to the three-backtick form of markdown
108108code block.
109109
110110 /**
111- # nested codefences confuse sundown => indentation + comment to
111+ # nested code fences confuse sundown => indentation + comment to
112112 # avoid failing tests
113113 ```
114114 // This is a testable code block
@@ -126,7 +126,7 @@ You can specify that the test's execution should fail with the `should_fail`
126126directive.
127127
128128 /**
129- # nested codefences confuse sundown => indentation + comment to
129+ # nested code fences confuse sundown => indentation + comment to
130130 # avoid failing tests
131131 ```should_fail
132132 // 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
138138` no_run ` directive.
139139
140140 /**
141- # nested codefences confuse sundown => indentation + comment to
141+ # nested code fences confuse sundown => indentation + comment to
142142 # avoid failing tests
143143 ```no_run
144144 // This code will be compiled but not executed
@@ -153,7 +153,7 @@ testing the code block (NB. the space after the `#` is required, so
153153that one can still write things like ` #[deriving(Eq)] ` ).
154154
155155 /**
156- # nested codefences confuse sundown => indentation + comment to
156+ # nested code fences confuse sundown => indentation + comment to
157157 # avoid failing tests
158158 ```rust
159159 # /!\ 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)]`).
162162 # these first five lines but a non breakable one.
163163 #
164164 # // showing 'fib' in this documentation would just be tedious and detracts from
165- # // what's actualy being documented.
165+ # // what's actually being documented.
166166 # fn fib(n: int) { n + 2 }
167167
168168 do spawn { fib(200); }
@@ -190,7 +190,7 @@ $ rustdoc --test lib.rs --test-args '--help'
190190~~~
191191
192192When testing a library, code examples will often show how functions are used,
193- and this code often requires ` use ` -ing paths from the crate. To accomodate this,
193+ and this code often requires ` use ` -ing paths from the crate. To accommodate this,
194194rustdoc will implicitly add ` extern crate <crate>; ` where ` <crate> ` is the name of
195195the crate being tested to the top of each code example. This means that rustdoc
196196must be able to find a compiled version of the library crate being tested. Extra
0 commit comments