Auto merge of #29138 - ykomatsu:trpl2, r=Manishearth

This commit is contained in:
bors 2015-10-21 14:45:48 +00:00
commit ea2dabf6b2
4 changed files with 8 additions and 8 deletions

View File

@ -48,7 +48,7 @@ Systems Level
Language](http://www.cs.indiana.edu/~eholk/papers/hips2013.pdf). Early GPU work by Eric Holk.
* [Parallel closures: a new twist on an old
idea](https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea)
- not exactly about rust, but by nmatsakis
- not exactly about Rust, but by nmatsakis
* [Patina: A Formalization of the Rust Programming
Language](ftp://ftp.cs.washington.edu/tr/2015/03/UW-CSE-15-03-02.pdf). Early
formalization of a subset of the type system, by Eric Reed.

View File

@ -204,7 +204,7 @@ borrow checker. Generally we know that such mutations won't happen in a nested f
to check.
For large, complicated programs, it becomes useful to put some things in `RefCell`s to make things
simpler. For example, a lot of the maps in [the `ctxt` struct][ctxt] in the rust compiler internals
simpler. For example, a lot of the maps in [the `ctxt` struct][ctxt] in the Rust compiler internals
are inside this wrapper. These are only modified once (during creation, which is not right after
initialization) or a couple of times in well-separated places. However, since this struct is
pervasively used everywhere, juggling mutable and immutable pointers would be hard (perhaps

View File

@ -150,7 +150,7 @@ owners!
So, we need some type that lets us have more than one reference to a value and
that we can share between threads, that is it must implement `Sync`.
We'll use `Arc<T>`, rust's standard atomic reference count type, which
We'll use `Arc<T>`, Rust's standard atomic reference count type, which
wraps a value up with some extra runtime bookkeeping which allows us to
share the ownership of the value between multiple references at the same time.

View File

@ -279,11 +279,11 @@ fn extension(file_name: &str) -> Option<&str> {
}
```
One other pattern that we find is very common is assigning a default value to
the case when an `Option` value is `None`. For example, maybe your program
assumes that the extension of a file is `rs` even if none is present. As you
might imagine, the case analysis for this is not specific to file
extensions - it can work with any `Option<T>`:
One other pattern we commonly find is assigning a default value to the case
when an `Option` value is `None`. For example, maybe your program assumes that
the extension of a file is `rs` even if none is present. As you might imagine,
the case analysis for this is not specific to file extensions - it can work
with any `Option<T>`:
```rust
fn unwrap_or<T>(option: Option<T>, default: T) -> T {