mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Typo fixes.

Browse Source
This commit is contained in:
Lindsey Kuper 2014-03-16 20:12:49 -04:00 committed by Alex Crichton
parent 168cd3a2f5
commit 783a00e796
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
src/doc/rustdoc.md
View File

@ -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