Skip to content

Rollup of 5 pull requests #27530

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Aug 5, 2015
2 changes: 1 addition & 1 deletion src/doc/nomicon/atomics.md
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,7 @@ fundamentally unsynchronized and compilers are free to aggressively optimize
them. In particular, data accesses are free to be reordered by the compiler on
the assumption that the program is single-threaded. The hardware is also free to
propagate the changes made in data accesses to other threads as lazily and
inconsistently as it wants. Mostly critically, data accesses are how data races
inconsistently as it wants. Most critically, data accesses are how data races
happen. Data accesses are very friendly to the hardware and compiler, but as
we've seen they offer *awful* semantics to try to write synchronized code with.
Actually, that's too weak.
Expand Down
2 changes: 1 addition & 1 deletion src/doc/nomicon/concurrency.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ an abstraction over them in a relatively uncontroversial way. Message passing,
green threads, and async APIs are all diverse enough that any abstraction over
them tends to involve trade-offs that we weren't willing to commit to for 1.0.

However the way Rust models concurrency makes it relatively easy design your own
However the way Rust models concurrency makes it relatively easy to design your own
concurrency paradigm as a library and have everyone else's code Just Work
with yours. Just require the right lifetimes and Send and Sync where appropriate
and you're off to the races. Or rather, off to the... not... having... races.
2 changes: 1 addition & 1 deletion src/doc/nomicon/destructors.md
Original file line number Diff line number Diff line change
Expand Up @@ -120,7 +120,7 @@ enum Link {
will have its inner Box field dropped if and only if an instance stores the
Next variant.

In general this works really nice because you don't need to worry about
In general this works really nicely because you don't need to worry about
adding/removing drops when you refactor your data layout. Still there's
certainly many valid usecases for needing to do trickier things with
destructors.
Expand Down
2 changes: 1 addition & 1 deletion src/doc/nomicon/drop-flags.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
% Drop Flags

The examples in the previous section introduce an interesting problem for Rust.
We have seen that's possible to conditionally initialize, deinitialize, and
We have seen that it's possible to conditionally initialize, deinitialize, and
reinitialize locations of memory totally safely. For Copy types, this isn't
particularly notable since they're just a random pile of bits. However types
with destructors are a different story: Rust needs to know whether to call a
Expand Down
2 changes: 1 addition & 1 deletion src/doc/nomicon/dropck.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
% Drop Check

We have seen how lifetimes provide us some fairly simple rules for ensuring
that never read dangling references. However up to this point we have only ever
that we never read dangling references. However up to this point we have only ever
interacted with the *outlives* relationship in an inclusive manner. That is,
when we talked about `'a: 'b`, it was ok for `'a` to live *exactly* as long as
`'b`. At first glance, this seems to be a meaningless distinction. Nothing ever
Expand Down
4 changes: 2 additions & 2 deletions src/doc/nomicon/send-and-sync.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,15 +3,15 @@
Not everything obeys inherited mutability, though. Some types allow you to
multiply alias a location in memory while mutating it. Unless these types use
synchronization to manage this access, they are absolutely not thread safe. Rust
captures this with through the `Send` and `Sync` traits.
captures this through the `Send` and `Sync` traits.

* A type is Send if it is safe to send it to another thread.
* A type is Sync if it is safe to share between threads (`&T` is Send).

Send and Sync are fundamental to Rust's concurrency story. As such, a
substantial amount of special tooling exists to make them work right. First and
foremost, they're [unsafe traits][]. This means that they are unsafe to
implement, and other unsafe code can that they are correctly
implement, and other unsafe code can assume that they are correctly
implemented. Since they're *marker traits* (they have no associated items like
methods), correctly implemented simply means that they have the intrinsic
properties an implementor should have. Incorrectly implementing Send or Sync can
Expand Down
4 changes: 2 additions & 2 deletions src/doc/nomicon/subtyping.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,8 +93,8 @@ fn main() {

The signature of `overwrite` is clearly valid: it takes mutable references to
two values of the same type, and overwrites one with the other. If `&mut T` was
variant over T, then `&mut &'a str` would be a subtype of `&mut &'static str`,
since `&'a str` is a subtype of `&'static str`. Therefore the lifetime of
variant over T, then `&mut &'static str` would be a subtype of `&mut &'a str`,
since `&'static str` is a subtype of `&'a str`. Therefore the lifetime of
`forever_str` would successfully be "shrunk" down to the shorter lifetime of
`string`, and `overwrite` would be called successfully. `string` would
subsequently be dropped, and `forever_str` would point to freed memory when we
Expand Down
2 changes: 1 addition & 1 deletion src/doc/nomicon/unchecked-uninit.md
Original file line number Diff line number Diff line change
Expand Up @@ -77,7 +77,7 @@ contain any `Drop` types.
However when working with uninitialized memory you need to be ever-vigilant for
Rust trying to drop values you make like this before they're fully initialized.
Every control path through that variable's scope must initialize the value
before it ends, if has a destructor.
before it ends, if it has a destructor.
*[This includes code panicking](unwinding.html)*.

And that's about it for working with uninitialized memory! Basically nothing
Expand Down
5 changes: 3 additions & 2 deletions src/doc/reference.md
Original file line number Diff line number Diff line change
Expand Up @@ -538,8 +538,9 @@ balanced, but they are otherwise not special.
In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the Rust
syntax named by _designator_. Valid designators are `item`, `block`, `stmt`,
`pat`, `expr`, `ty` (type), `ident`, `path`, `tt` (either side of the `=>`
in macro rules). In the transcriber, the designator is already known, and so
only the name of a matched nonterminal comes after the dollar sign.
in macro rules), and `meta` (contents of an attribute). In the transcriber, the
designator is already known, and so only the name of a matched nonterminal comes
after the dollar sign.

In both the matcher and transcriber, the Kleene star-like operator indicates
repetition. The Kleene star operator consists of `$` and parentheses, optionally
Expand Down
Loading