Rollup of 10 pull requests

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 :=
-CFG_GCCISH_CXXFLAGS_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_LINK_FLAGS_x86_64-pc-windows-msvc :=
 CFG_GCCISH_DEF_FLAG_x86_64-pc-windows-msvc :=
 CFG_LLC_FLAGS_x86_64-pc-windows-msvc :=

src/doc/reference.md

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

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

@@ -81,7 +81,3 @@ 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.

src/doc/trpl/dining-philosophers.md

@@ -674,9 +674,13 @@ 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. 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. 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.
 
 With this, our program works! Only two philosophers can eat at any one time,
 and so you’ll get some output like this:

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:
 

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’, and we
-can do it by returning `self`.
+original example, `foo.bar().baz()`? This is called ‘method chaining’. Let’s
+look at an example:
 
 ```rust
 struct Circle {

src/doc/trpl/patterns.md

@@ -154,6 +154,31 @@ 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:

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 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:
+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:
 
 * one or more references (`&T`) to a resource.
 * exactly one mutable reference (`&mut T`)

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 -> uint
+impl Convert<int> for uint { ... } // uint -> int
 ```
 
 Now imagine there is some code like the following:

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 "_ZN3foo3bar" => "foo::bar".
+// For example, "_ZN4testE" => "test" and "_ZN3foo3barE" => "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