---

yaml
---
r: 212404
b: refs/heads/master
c: a9899a7
h: refs/heads/master
v: v3

Author: steveklabnik

[refs]

@@ -1,5 +1,5 @@
 ---
-refs/heads/master: 496fe4d51a5b44f6072f24b016f8f1199c101448
+refs/heads/master: a9899a73533c542efcc797405e3c09882da9d7fa
 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

@@ -78,3 +78,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/ffi.md

@@ -342,8 +342,10 @@ 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 libraries and frameworks are propagated to the final artifact
-boundary, while static libraries are not propagated at all.
+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.
 
 A few examples of how this model can be used are:
 

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