---

yaml
---
r: 236213
b: refs/heads/stable
c: 6112b22
h: refs/heads/master
i:
  236211: 67c1665
v: v3

Author: vadimcn

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: afae2ff723393b3ab4ccffef6ac7c6d1809e2da0
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: d877e6540431d99b0945a3d27eeb466b0d693902
+refs/heads/stable: 6112b220782134c70516301f7dab2e05e3283f54
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/.travis.yml

@@ -20,7 +20,8 @@ sudo: false
 before_script:
   - ./configure --enable-ccache
 script:
-  - make tidy check -j4
+  - make tidy
+  - make rustc-stage1 -j4
 
 env:
   - CXX=/usr/bin/g++-4.7

branches/stable/RELEASES.md

@@ -16,12 +16,6 @@ Highlights
   jobs). It's not enabled by default, but will be "in the near
   future". It can be activated with the `-C codegen-units=N` flag to
   `rustc`.
-* This is the first release with [experimental support for linking
-  with the MSVC linker and lib C on Windows (instead of using the GNU
-  variants via MinGW)][win]. It is yet recommended only for the most
-  intrepid Rusticians.
-* Benchmark compilations are showing a 30% improvement in
-  bootstrapping over 1.1.
 
 Breaking Changes
 ----------------
@@ -37,10 +31,6 @@ Breaking Changes
 * [The `#[packed]` attribute is no longer silently accepted by the
   compiler][packed]. This attribute did nothing and code that
   mentioned it likely did not work as intended.
-* Associated type defaults are [now behind the
-  `associated_type_defaults` feature gate][ad]. In 1.1 associated type
-  defaults *did not work*, but could be mentioned syntactically. As
-  such this breakage has minimal impact.
 
 Language
 --------
@@ -56,11 +46,12 @@ Libraries
   `LinkedList`, `VecDeque`, `EnumSet`, `BinaryHeap`, `VecMap`,
   `BTreeSet` and `BTreeMap`. [RFC][extend-rfc].
 * The [`iter::once`] function returns an iterator that yields a single
-  element, and [`iter::empty`] returns an iterator that yields no
+  element.
+* The [`iter::empty`] function returns an iterator that yields no
   elements.
 * The [`matches`] and [`rmatches`] methods on `str` return iterators
   over substring matches.
-* [`Cell`] and [`RefCell`] both implement `Eq`.
+* [`Cell`] and [`RefCell`] both implement [`Eq`].
 * A number of methods for wrapping arithmetic are added to the
   integral types, [`wrapping_div`], [`wrapping_rem`],
   [`wrapping_neg`], [`wrapping_shl`], [`wrapping_shr`]. These are in
@@ -153,8 +144,6 @@ Misc
 [dst]: https://github.com/rust-lang/rfcs/blob/master/text/0982-dst-coercion.md
 [parcodegen]: https://github.com/rust-lang/rust/pull/26018
 [packed]: https://github.com/rust-lang/rust/pull/25541
-[ad]: https://github.com/rust-lang/rust/pull/27382
-[win]: https://github.com/rust-lang/rust/pull/25350
 
 Version 1.1.0 (June 2015)
 =========================

branches/stable/src/doc/reference.md

@@ -1199,8 +1199,8 @@ An example of an `enum` item and its use:
 
 ```
 enum Animal {
-    Dog,
-    Cat,
+  Dog,
+  Cat
 }
 
 let mut a: Animal = Animal::Dog;

branches/stable/src/doc/tarpl/README.md

@@ -2,33 +2,38 @@
 
 # NOTE: This is a draft document, and may contain serious errors
 
-So you've played around with Rust a bit. You've written a few simple programs
-and you think you grok the basics. Maybe you've even read through *[The Rust
-Programming Language][trpl]* (TRPL). Now you want to get neck-deep in all the
+So you've played around with Rust a bit. You've written a few simple programs and
+you think you grok the basics. Maybe you've even read through
+*[The Rust Programming Language][trpl]*. Now you want to get neck-deep in all the
 nitty-gritty details of the language. You want to know those weird corner-cases.
-You want to know what the heck `unsafe` really means, and how to properly use
-it. This is the book for you.
+You want to know what the heck `unsafe` really means, and how to properly use it.
+This is the book for you.
 
-To be clear, this book goes into serious detail. We're going to dig into
+To be clear, this book goes into *serious* detail. We're going to dig into
 exception-safety and pointer aliasing. We're going to talk about memory
 models. We're even going to do some type-theory. This is stuff that you
-absolutely don't need to know to write fast and safe Rust programs.
+absolutely *don't* need to know to write fast and safe Rust programs.
 You could probably close this book *right now* and still have a productive
 and happy career in Rust.
 
-However if you intend to write unsafe code -- or just really want to dig into
-the guts of the language -- this book contains invaluable information.
+However if you intend to write unsafe code -- or just *really* want to dig into
+the guts of the language -- this book contains *invaluable* information.
 
-Unlike TRPL we will be assuming considerable prior knowledge. In particular, you
-should be comfortable with basic systems programming and basic Rust. If you
-don't feel comfortable with these topics, you should consider [reading
-TRPL][trpl], though we will not be assuming that you have. You can skip
-straight to this book if you want; just know that we won't be explaining
-everything from the ground up.
+Unlike *The Rust Programming Language* we *will* be assuming considerable prior
+knowledge. In particular, you should be comfortable with:
 
-Due to the nature of advanced Rust programming, we will be spending a lot of
-time talking about *safety* and *guarantees*. In particular, a significant
-portion of the book will be dedicated to correctly writing and understanding
-Unsafe Rust.
+* Basic Systems Programming:
+    * Pointers
+    * [The stack and heap][]
+    * The memory hierarchy (caches)
+    * Threads
+
+* [Basic Rust][]
+
+Due to the nature of advanced Rust programming, we will be spending a lot of time
+talking about *safety* and *guarantees*. In particular, a significant portion of
+the book will be dedicated to correctly writing and understanding Unsafe Rust.
 
 [trpl]: ../book/
+[The stack and heap]: ../book/the-stack-and-the-heap.html
+[Basic Rust]: ../book/syntax-and-semantics.html

branches/stable/src/doc/tarpl/SUMMARY.md

@@ -10,7 +10,7 @@
 * [Ownership](ownership.md)
 	* [References](references.md)
 	* [Lifetimes](lifetimes.md)
-	* [Limits of Lifetimes](lifetime-mismatch.md)
+	* [Limits of lifetimes](lifetime-mismatch.md)
 	* [Lifetime Elision](lifetime-elision.md)
 	* [Unbounded Lifetimes](unbounded-lifetimes.md)
 	* [Higher-Rank Trait Bounds](hrtb.md)

branches/stable/src/doc/tarpl/atomics.md

@@ -17,7 +17,7 @@ face.
 The C11 memory model is fundamentally about trying to bridge the gap between the
 semantics we want, the optimizations compilers want, and the inconsistent chaos
 our hardware wants. *We* would like to just write programs and have them do
-exactly what we said but, you know, fast. Wouldn't that be great?
+exactly what we said but, you know, *fast*. Wouldn't that be great?
 
 
 
@@ -35,20 +35,20 @@ y = 3;
 x = 2;
 ```
 
-The compiler may conclude that it would be best if your program did
+The compiler may conclude that it would *really* be best if your program did
 
 ```rust,ignore
 x = 2;
 y = 3;
 ```
 
-This has inverted the order of events and completely eliminated one event.
+This has inverted the order of events *and* completely eliminated one event.
 From a single-threaded perspective this is completely unobservable: after all
 the statements have executed we are in exactly the same state. But if our
-program is multi-threaded, we may have been relying on `x` to actually be
-assigned to 1 before `y` was assigned. We would like the compiler to be
+program is multi-threaded, we may have been relying on `x` to *actually* be
+assigned to 1 before `y` was assigned. We would *really* like the compiler to be
 able to make these kinds of optimizations, because they can seriously improve
-performance. On the other hand, we'd also like to be able to depend on our
+performance. On the other hand, we'd really like to be able to depend on our
 program *doing the thing we said*.
 
 
@@ -57,15 +57,15 @@ program *doing the thing we said*.
 # Hardware Reordering
 
 On the other hand, even if the compiler totally understood what we wanted and
-respected our wishes, our hardware might instead get us in trouble. Trouble
+respected our wishes, our *hardware* might instead get us in trouble. Trouble
 comes from CPUs in the form of memory hierarchies. There is indeed a global
 shared memory space somewhere in your hardware, but from the perspective of each
 CPU core it is *so very far away* and *so very slow*. Each CPU would rather work
-with its local cache of the data and only go through all the anguish of
-talking to shared memory only when it doesn't actually have that memory in
+with its local cache of the data and only go through all the *anguish* of
+talking to shared memory *only* when it doesn't actually have that memory in
 cache.
 
-After all, that's the whole point of the cache, right? If every read from the
+After all, that's the whole *point* of the cache, right? If every read from the
 cache had to run back to shared memory to double check that it hadn't changed,
 what would the point be? The end result is that the hardware doesn't guarantee
 that events that occur in the same order on *one* thread, occur in the same
@@ -99,13 +99,13 @@ provides weak ordering guarantees. This has two consequences for concurrent
 programming:
 
 * Asking for stronger guarantees on strongly-ordered hardware may be cheap or
-  even free because they already provide strong guarantees unconditionally.
+  even *free* because they already provide strong guarantees unconditionally.
   Weaker guarantees may only yield performance wins on weakly-ordered hardware.
 
-* Asking for guarantees that are too weak on strongly-ordered hardware is
+* Asking for guarantees that are *too* weak on strongly-ordered hardware   is
   more likely to *happen* to work, even though your program is strictly
-  incorrect. If possible, concurrent algorithms should be tested on
-  weakly-ordered hardware.
+  incorrect. If possible, concurrent algorithms should be tested on   weakly-
+  ordered hardware.
 
 
 
@@ -115,10 +115,10 @@ programming:
 
 The C11 memory model attempts to bridge the gap by allowing us to talk about the
 *causality* of our program. Generally, this is by establishing a *happens
-before* relationship between parts of the program and the threads that are
+before* relationships between parts of the program and the threads that are
 running them. This gives the hardware and compiler room to optimize the program
 more aggressively where a strict happens-before relationship isn't established,
-but forces them to be more careful where one is established. The way we
+but forces them to be more careful where one *is* established. The way we
 communicate these relationships are through *data accesses* and *atomic
 accesses*.
 
@@ -130,10 +130,8 @@ 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
 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.
-
-**It is literally impossible to write correct synchronized code using only data
-accesses.**
+Actually, that's too weak. *It is literally impossible to write correct
+synchronized code using only data accesses*.
 
 Atomic accesses are how we tell the hardware and compiler that our program is
 multi-threaded. Each atomic access can be marked with an *ordering* that
@@ -143,10 +141,7 @@ they *can't* do. For the compiler, this largely revolves around re-ordering of
 instructions. For the hardware, this largely revolves around how writes are
 propagated to other threads. The set of orderings Rust exposes are:
 
-* Sequentially Consistent (SeqCst)
-* Release
-* Acquire
-* Relaxed
+* Sequentially Consistent (SeqCst) Release Acquire Relaxed
 
 (Note: We explicitly do not expose the C11 *consume* ordering)
 
@@ -159,13 +154,13 @@ synchronize"
 
 Sequentially Consistent is the most powerful of all, implying the restrictions
 of all other orderings. Intuitively, a sequentially consistent operation
-cannot be reordered: all accesses on one thread that happen before and after a
-SeqCst access stay before and after it. A data-race-free program that uses
+*cannot* be reordered: all accesses on one thread that happen before and after a
+SeqCst access *stay* before and after it. A data-race-free program that uses
 only sequentially consistent atomics and data accesses has the very nice
 property that there is a single global execution of the program's instructions
 that all threads agree on. This execution is also particularly nice to reason
 about: it's just an interleaving of each thread's individual executions. This
-does not hold if you start using the weaker atomic orderings.
+*does not* hold if you start using the weaker atomic orderings.
 
 The relative developer-friendliness of sequential consistency doesn't come for
 free. Even on strongly-ordered platforms sequential consistency involves
@@ -175,8 +170,8 @@ In practice, sequential consistency is rarely necessary for program correctness.
 However sequential consistency is definitely the right choice if you're not
 confident about the other memory orders. Having your program run a bit slower
 than it needs to is certainly better than it running incorrectly! It's also
-mechanically trivial to downgrade atomic operations to have a weaker
-consistency later on. Just change `SeqCst` to `Relaxed` and you're done! Of
+*mechanically* trivial to downgrade atomic operations to have a weaker
+consistency later on. Just change `SeqCst` to e.g. `Relaxed` and you're done! Of
 course, proving that this transformation is *correct* is a whole other matter.
 
 
@@ -188,15 +183,15 @@ Acquire and Release are largely intended to be paired. Their names hint at their
 use case: they're perfectly suited for acquiring and releasing locks, and
 ensuring that critical sections don't overlap.
 
-Intuitively, an acquire access ensures that every access after it stays after
+Intuitively, an acquire access ensures that every access after it *stays* after
 it. However operations that occur before an acquire are free to be reordered to
 occur after it. Similarly, a release access ensures that every access before it
-stays before it. However operations that occur after a release are free to be
+*stays* before it. However operations that occur after a release are free to be
 reordered to occur before it.
 
 When thread A releases a location in memory and then thread B subsequently
 acquires *the same* location in memory, causality is established. Every write
-that happened before A's release will be observed by B after its release.
+that happened *before* A's release will be observed by B *after* its release.
 However no causality is established with any other threads. Similarly, no
 causality is established if A and B access *different* locations in memory.
 
@@ -235,7 +230,7 @@ weakly-ordered platforms.
 # Relaxed
 
 Relaxed accesses are the absolute weakest. They can be freely re-ordered and
-provide no happens-before relationship. Still, relaxed operations are still
+provide no happens-before relationship. Still, relaxed operations *are* still
 atomic. That is, they don't count as data accesses and any read-modify-write
 operations done to them occur atomically. Relaxed operations are appropriate for
 things that you definitely want to happen, but don't particularly otherwise care

branches/stable/src/doc/tarpl/borrow-splitting.md

@@ -2,7 +2,7 @@
 
 The mutual exclusion property of mutable references can be very limiting when
 working with a composite structure. The borrow checker understands some basic
-stuff, but will fall over pretty easily. It does understand structs
+stuff, but will fall over pretty easily. It *does* understand structs
 sufficiently to know that it's possible to borrow disjoint fields of a struct
 simultaneously. So this works today:
 
@@ -27,27 +27,19 @@ However borrowck doesn't understand arrays or slices in any way, so this doesn't
 work:
 
 ```rust,ignore
-let mut x = [1, 2, 3];
+let x = [1, 2, 3];
 let a = &mut x[0];
 let b = &mut x[1];
 println!("{} {}", a, b);
 ```
 
 ```text
-<anon>:4:14: 4:18 error: cannot borrow `x[..]` as mutable more than once at a time
-<anon>:4 let b = &mut x[1];
-                      ^~~~
-<anon>:3:14: 3:18 note: previous borrow of `x[..]` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `x[..]` until the borrow ends
-<anon>:3 let a = &mut x[0];
-                      ^~~~
-<anon>:6:2: 6:2 note: previous borrow ends here
-<anon>:1 fn main() {
-<anon>:2 let mut x = [1, 2, 3];
-<anon>:3 let a = &mut x[0];
-<anon>:4 let b = &mut x[1];
-<anon>:5 println!("{} {}", a, b);
-<anon>:6 }
-         ^
+<anon>:3:18: 3:22 error: cannot borrow immutable indexed content `x[..]` as mutable
+<anon>:3     let a = &mut x[0];
+                          ^~~~
+<anon>:4:18: 4:22 error: cannot borrow immutable indexed content `x[..]` as mutable
+<anon>:4     let b = &mut x[1];
+                          ^~~~
 error: aborting due to 2 previous errors
 ```
 
@@ -58,7 +50,7 @@ to the same value.
 
 In order to "teach" borrowck that what we're doing is ok, we need to drop down
 to unsafe code. For instance, mutable slices expose a `split_at_mut` function
-that consumes the slice and returns two mutable slices. One for everything to
+that consumes the slice and returns *two* mutable slices. One for everything to
 the left of the index, and one for everything to the right. Intuitively we know
 this is safe because the slices don't overlap, and therefore alias. However
 the implementation requires some unsafety:
@@ -101,10 +93,10 @@ completely incompatible with this API, as it would produce multiple mutable
 references to the same object!
 
 However it actually *does* work, exactly because iterators are one-shot objects.
-Everything an IterMut yields will be yielded at most once, so we don't
-actually ever yield multiple mutable references to the same piece of data.
+Everything an IterMut yields will be yielded *at most* once, so we don't
+*actually* ever yield multiple mutable references to the same piece of data.
 
-Perhaps surprisingly, mutable iterators don't require unsafe code to be
+Perhaps surprisingly, mutable iterators *don't* require unsafe code to be
 implemented for many types!
 
 For instance here's a singly linked list:

branches/stable/src/doc/tarpl/casts.md

@@ -1,13 +1,13 @@
 % Casts
 
 Casts are a superset of coercions: every coercion can be explicitly
-invoked via a cast. However some conversions require a cast.
+invoked via a cast. However some conversions *require* a cast.
 While coercions are pervasive and largely harmless, these "true casts"
 are rare and potentially dangerous. As such, casts must be explicitly invoked
 using the `as` keyword: `expr as Type`.
 
 True casts generally revolve around raw pointers and the primitive numeric
-types. Even though they're dangerous, these casts are infallible at runtime.
+types. Even though they're dangerous, these casts are *infallible* at runtime.
 If a cast triggers some subtle corner case no indication will be given that
 this occurred. The cast will simply succeed. That said, casts must be valid
 at the type level, or else they will be prevented statically. For instance,