@@ -43,7 +43,7 @@ pub fn recalibrate() {
43
43
Doc comments are markdown, and are currently parsed with the
44
44
[ sundown] [ sundown ] library. rustdoc does not yet do any fanciness such as
45
45
referencing 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
47
47
generated documentation:
48
48
49
49
~~~
@@ -79,11 +79,11 @@ rustdoc can also generate JSON, for consumption by other tools, with
79
79
80
80
# Using the Documentation
81
81
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
83
83
writes a library with. Every kind of item (function, struct, etc) has its own
84
84
color, and one can always click on a colored type to jump to its
85
85
documentation. 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
87
87
required for the search.
88
88
89
89
[ sundown ] : https://github.com/vmg/sundown/
@@ -108,7 +108,7 @@ code, the `ignore` string can be added to the three-backtick form of markdown
108
108
code block.
109
109
110
110
/**
111
- # nested codefences confuse sundown => indentation + comment to
111
+ # nested code fences confuse sundown => indentation + comment to
112
112
# avoid failing tests
113
113
```
114
114
// This is a testable code block
@@ -126,7 +126,7 @@ You can specify that the test's execution should fail with the `should_fail`
126
126
directive.
127
127
128
128
/**
129
- # nested codefences confuse sundown => indentation + comment to
129
+ # nested code fences confuse sundown => indentation + comment to
130
130
# avoid failing tests
131
131
```should_fail
132
132
// 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
138
138
` no_run ` directive.
139
139
140
140
/**
141
- # nested codefences confuse sundown => indentation + comment to
141
+ # nested code fences confuse sundown => indentation + comment to
142
142
# avoid failing tests
143
143
```no_run
144
144
// This code will be compiled but not executed
@@ -153,7 +153,7 @@ testing the code block (NB. the space after the `#` is required, so
153
153
that one can still write things like ` #[deriving(Eq)] ` ).
154
154
155
155
/**
156
- # nested codefences confuse sundown => indentation + comment to
156
+ # nested code fences confuse sundown => indentation + comment to
157
157
# avoid failing tests
158
158
```rust
159
159
# /!\ 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)]`).
162
162
# these first five lines but a non breakable one.
163
163
#
164
164
# // showing 'fib' in this documentation would just be tedious and detracts from
165
- # // what's actualy being documented.
165
+ # // what's actually being documented.
166
166
# fn fib(n: int) { n + 2 }
167
167
168
168
do spawn { fib(200); }
@@ -190,7 +190,7 @@ $ rustdoc --test lib.rs --test-args '--help'
190
190
~~~
191
191
192
192
When 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,
194
194
rustdoc will implicitly add ` extern crate <crate>; ` where ` <crate> ` is the name of
195
195
the crate being tested to the top of each code example. This means that rustdoc
196
196
must be able to find a compiled version of the library crate being tested. Extra
0 commit comments