---

yaml
---
r: 212410
b: refs/heads/master
c: 9db9449
h: refs/heads/master
v: v3

Author: steveklabnik

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 9bcae312a39c4ecc93449e40e86d05b776eadd16
+refs/heads/master: 9db94498363b4cdf9252084a576bfdb5f13b082f
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: ba0e1cd8147d452c356aacb29fb87568ca26f111
 refs/heads/try: 1864973ae17213c5a58c4dd3f9af6d1b6c7d2e05

trunk/mk/cfg/x86_64-pc-windows-msvc.mk

@@ -9,8 +9,8 @@ CFG_STATIC_LIB_NAME_x86_64-pc-windows-msvc=$(1).lib
 CFG_LIB_GLOB_x86_64-pc-windows-msvc=$(1)-*.dll
 CFG_LIB_DSYM_GLOB_x86_64-pc-windows-msvc=$(1)-*.dylib.dSYM
 CFG_JEMALLOC_CFLAGS_x86_64-pc-windows-msvc :=
-CFG_GCCISH_CFLAGS_x86_64-pc-windows-msvc := -MD
-CFG_GCCISH_CXXFLAGS_x86_64-pc-windows-msvc := -MD
+CFG_GCCISH_CFLAGS_x86_64-pc-windows-msvc :=
+CFG_GCCISH_CXXFLAGS_x86_64-pc-windows-msvc :=
 CFG_GCCISH_LINK_FLAGS_x86_64-pc-windows-msvc :=
 CFG_GCCISH_DEF_FLAG_x86_64-pc-windows-msvc :=
 CFG_LLC_FLAGS_x86_64-pc-windows-msvc :=

trunk/src/doc/reference.md

@@ -1367,6 +1367,7 @@ Traits can include default implementations of methods, as in:
 ```
 trait Foo {
     fn bar(&self);
+
     fn baz(&self) { println!("We called baz."); }
 }
 ```

trunk/src/doc/trpl/const-and-static.md

@@ -64,7 +64,10 @@ unsafe {
 
 [unsafe]: unsafe.html
 
-Furthermore, any type stored in a `static` must be `Sync`.
+Furthermore, any type stored in a `static` must be `Sync`, and may not have
+a [`Drop`][drop] implementation.
+
+[drop]: drop.html
 
 # Initializing
 
@@ -78,3 +81,7 @@ Almost always, if you can choose between the two, choose `const`. It’s pretty
 rare that you actually want a memory location associated with your constant,
 and using a const allows for optimizations like constant propagation not only
 in your crate but downstream crates.
+
+A const can be thought of as a `#define` in C: it has metadata overhead but it
+has no runtime overhead. “Should I use a #define or a static in C,” is largely
+the same question as whether you should use a const or a static in Rust.

trunk/src/doc/trpl/dining-philosophers.md

@@ -674,13 +674,9 @@ let handles: Vec<_> = philosophers.into_iter().map(|p| {
 
 Finally, inside of our `map()`/`collect()` loop, we call `table.clone()`. The
 `clone()` method on `Arc<T>` is what bumps up the reference count, and when it
-goes out of scope, it decrements the count. This is needed so that we know how
-many references to `table` exist across our threads. If we didn’t have a count,
-we wouldn’t know how to deallocate it.
-
-You’ll notice we can introduce a new binding to `table` here, and it will
-shadow the old one. This is often used so that you don’t need to come up with
-two unique names.
+goes out of scope, it decrements the count. You’ll notice we can introduce a
+new binding to `table` here, and it will shadow the old one. This is often used
+so that you don’t need to come up with two unique names.
 
 With this, our program works! Only two philosophers can eat at any one time,
 and so you’ll get some output like this:

trunk/src/doc/trpl/ffi.md

@@ -342,10 +342,8 @@ Note that frameworks are only available on OSX targets.
 The different `kind` values are meant to differentiate how the native library
 participates in linkage. From a linkage perspective, the rust compiler creates
 two flavors of artifacts: partial (rlib/staticlib) and final (dylib/binary).
-Native dynamic library and framework dependencies are propagated to the final
-artifact boundary, while static library dependencies are not propagated at
-all, because the static libraries are integrated directly into the subsequent
-artifact.
+Native dynamic libraries and frameworks are propagated to the final artifact
+boundary, while static libraries are not propagated at all.
 
 A few examples of how this model can be used are:
 

trunk/src/doc/trpl/method-syntax.md

@@ -86,8 +86,8 @@ impl Circle {
 # Chaining method calls
 
 So, now we know how to call a method, such as `foo.bar()`. But what about our
-original example, `foo.bar().baz()`? This is called ‘method chaining’. Let’s
-look at an example:
+original example, `foo.bar().baz()`? This is called ‘method chaining’, and we
+can do it by returning `self`.
 
 ```rust
 struct Circle {

trunk/src/doc/trpl/patterns.md

@@ -154,31 +154,6 @@ match x {
 
 This prints `Got an int!`.
 
-If you’re using `if` with multiple patterns, the `if` applies to both sides:
-
-```rust
-let x = 4;
-let y = false;
-
-match x {
-    4 | 5 if y => println!("yes"),
-    _ => println!("no"),
-}
-```
-
-This prints `no`, because the `if` applies to the whole of `4 | 5`, and not to
-just the `5`, In other words, the the precedence of `if` behaves like this:
-
-```text
-(4 | 5) if y => ...
-```
-
-not this:
-
-```text
-4 | (5 if y) => ...
-```
-
 # ref and ref mut
 
 If you want to get a [reference][ref], use the `ref` keyword:

trunk/src/doc/trpl/references-and-borrowing.md

@@ -151,9 +151,9 @@ As it turns out, there are rules.
 
 Here’s the rules about borrowing in Rust:
 
-First, any borrow must last for a scope no greater than that of the owner.
-Second, you may have one or the other of these two kinds of borrows, but not
-both at the same time:
+First, any borrow must last for a smaller scope than the owner. Second, you may
+have one or the other of these two kinds of borrows, but not both at the same
+time:
 
 * one or more references (`&T`) to a resource.
 * exactly one mutable reference (`&mut T`)

trunk/src/librustc/middle/traits/README.md

@@ -120,7 +120,7 @@ implement `Convert` like so:
 
 ```rust
 impl Convert<uint> for int { ... } // int -> uint
-impl Convert<int> for uint { ... } // uint -> int
+impl Convert<int> for uint { ... } // uint -> uint
 ```
 
 Now imagine there is some code like the following:

trunk/src/libstd/sys/common/backtrace.rs

@@ -27,7 +27,7 @@ pub const HEX_WIDTH: usize = 10;
 // 2. For each element of the path, emit the length plus the element
 // 3. End the path with "E"
 //
-// For example, "_ZN4testE" => "test" and "_ZN3foo3barE" => "foo::bar".
+// For example, "_ZN4testE" => "test" and "_ZN3foo3bar" => "foo::bar".
 //
 // We're the ones printing our backtraces, so we can't rely on anything else to
 // demangle our symbols. It's *much* nicer to look at demangled symbols, so