auto merge of #13640 : jbcrail/rust/spelling-updates, r=alexcrichton
This commit is contained in:
commit
a27dc534e4
@ -29,7 +29,7 @@ let x: int = 42;
|
||||
let y: ~str = format!("{:t}", x); // binary
|
||||
let y: ~str = format!("{:o}", x); // octal
|
||||
let y: ~str = format!("{:x}", x); // lowercase hexadecimal
|
||||
let y: ~str = format!("{:X}", x); // uppercase hexidecimal
|
||||
let y: ~str = format!("{:X}", x); // uppercase hexadecimal
|
||||
~~~
|
||||
|
||||
**String to int, in non-base-10**
|
||||
|
@ -337,7 +337,7 @@ Besides classical synchronization mechanisms like mutexes, one possibility in
|
||||
Rust is to use channels (in `std::comm`) to forward data from the C thread
|
||||
that invoked the callback into a Rust task.
|
||||
|
||||
If an asychronous callback targets a special object in the Rust address space
|
||||
If an asynchronous callback targets a special object in the Rust address space
|
||||
it is also absolutely necessary that no more callbacks are performed by the
|
||||
C library after the respective Rust object gets destroyed.
|
||||
This can be achieved by unregistering the callback in the object's
|
||||
|
@ -561,7 +561,7 @@ points at a static constant).
|
||||
|
||||
Lifetimes can be named and referenced. For example, the special lifetime
|
||||
`'static`, which does not go out of scope, can be used to create global
|
||||
variables and communicate between tasks (see the manual for usecases).
|
||||
variables and communicate between tasks (see the manual for use cases).
|
||||
|
||||
## Parameter Lifetimes
|
||||
|
||||
|
@ -226,7 +226,7 @@ Now here's the exciting part:
|
||||
because `numbers` is an owned type,
|
||||
when it is sent across the channel,
|
||||
it is actually *moved*,
|
||||
transfering ownership of `numbers` between tasks.
|
||||
transferring ownership of `numbers` between tasks.
|
||||
This ownership transfer is *very fast* -
|
||||
in this case simply copying a pointer -
|
||||
while also ensuring that the original owning task cannot create data races by continuing to read or write to `numbers` in parallel with the new owner.
|
||||
@ -318,7 +318,7 @@ fn main() {
|
||||
This is almost exactly the same,
|
||||
except that this time `numbers` is first put into an `Arc`.
|
||||
`Arc::new` creates the `Arc`,
|
||||
`.clone()` makes another `Arc` that referrs to the same contents.
|
||||
`.clone()` makes another `Arc` that refers to the same contents.
|
||||
So we clone the `Arc` for each task,
|
||||
send that clone down the channel,
|
||||
and then use it to print out a number.
|
||||
|
@ -295,7 +295,7 @@ Raw string literals do not process any escapes. They start with the character
|
||||
`U+0022` (double-quote) character. The _raw string body_ is not defined in the
|
||||
EBNF grammar above: it can contain any sequence of Unicode characters and is
|
||||
terminated only by another `U+0022` (double-quote) character, followed by the
|
||||
same number of `U+0023` (`#`) characters that preceeded the opening `U+0022`
|
||||
same number of `U+0023` (`#`) characters that preceded the opening `U+0022`
|
||||
(double-quote) character.
|
||||
|
||||
All Unicode characters contained in the raw string body represent themselves,
|
||||
@ -2256,7 +2256,7 @@ fn main() {
|
||||
Certain aspects of Rust may be implemented in the compiler, but they're not
|
||||
necessarily ready for every-day use. These features are often of "prototype
|
||||
quality" or "almost production ready", but may not be stable enough to be
|
||||
considered a full-fleged language feature.
|
||||
considered a full-fledged language feature.
|
||||
|
||||
For this reason, Rust recognizes a special crate-level attribute of the form:
|
||||
|
||||
@ -4005,7 +4005,7 @@ dependencies will be used:
|
||||
could only be found in an `rlib` format. Remember that `staticlib` formats
|
||||
are always ignored by `rustc` for crate-linking purposes.
|
||||
|
||||
2. If a static library is being produced, all upstream dependecies are
|
||||
2. If a static library is being produced, all upstream dependencies are
|
||||
required to be available in `rlib` formats. This requirement stems from the
|
||||
same reasons that a dynamic library must have all dynamic dependencies.
|
||||
|
||||
|
@ -74,11 +74,11 @@ struct Octal;
|
||||
#[deriving(Clone, Eq)]
|
||||
struct Decimal;
|
||||
|
||||
/// A hexidecimal (base 16) radix, formatted with lower-case characters
|
||||
/// A hexadecimal (base 16) radix, formatted with lower-case characters
|
||||
#[deriving(Clone, Eq)]
|
||||
struct LowerHex;
|
||||
|
||||
/// A hexidecimal (base 16) radix, formatted with upper-case characters
|
||||
/// A hexadecimal (base 16) radix, formatted with upper-case characters
|
||||
#[deriving(Clone, Eq)]
|
||||
pub struct UpperHex;
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user