---

yaml
---
r: 229331
b: refs/heads/try
c: 8856927
h: refs/heads/master
i:
  229329: 622a459
  229327: e5ec5a8
v: v3

Author: bors

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: aca2057ed5fb7af3f8905b2bc01f72fa001c35c8
 refs/heads/snap-stage3: 1af31d4974e33027a68126fa5a5a3c2c6491824f
-refs/heads/try: cfcd449c4c36c68541c3389878e3262dac5e4746
+refs/heads/try: 8856927f649d9ce80ff52377ac2389a2798a7033
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try/src/doc/nomicon/exotic-sizes.md

@@ -85,8 +85,8 @@ support values.
 Safe code need not worry about ZSTs, but *unsafe* code must be careful about the
 consequence of types with no size. In particular, pointer offsets are no-ops,
 and standard allocators (including jemalloc, the one used by default in Rust)
-generally consider passing in `0` for the size of an allocation as Undefined
-Behaviour.
+may return `nullptr` when a zero-sized allocation is requested, which is
+indistinguishable from out of memory.
 
 
 

branches/try/src/doc/nomicon/lifetimes.md

@@ -52,8 +52,7 @@ likely desugar to the following:
 }
 ```
 
-Wow. That's... awful. Let's all take a moment to thank Rust for being a
-diabetes-inducing torrent of syrupy-goodness.
+Wow. That's... awful. Let's all take a moment to thank Rust for making this easier.
 
 Actually passing references to outer scopes will cause Rust to infer
 a larger lifetime:

branches/try/src/doc/nomicon/repr-rust.md

@@ -36,9 +36,9 @@ struct A {
 }
 ```
 
-will be 32-bit aligned assuming these primitives are aligned to their size.
-It will therefore have a size that is a multiple of 32-bits. It will potentially
-*really* become:
+will be 32-bit aligned on an architecture that aligns these primitives to their
+respective sizes. The whole struct will therefore have a size that is a multiple
+of 32-bits. It will potentially become:
 
 ```rust
 struct A {
@@ -50,10 +50,10 @@ struct A {
 }
 ```
 
-There is *no indirection* for these types; all data is stored contiguously as
-you would expect in C. However with the exception of arrays (which are densely
-packed and in-order), the layout of data is not by default specified in Rust.
-Given the two following struct definitions:
+There is *no indirection* for these types; all data is stored within the struct,
+as you would expect in C. However with the exception of arrays (which are
+densely packed and in-order), the layout of data is not by default specified in
+Rust. Given the two following struct definitions:
 
 ```rust
 struct A {
@@ -62,18 +62,17 @@ struct A {
 }
 
 struct B {
-    x: i32,
+    a: i32,
     b: u64,
 }
 ```
 
 Rust *does* guarantee that two instances of A have their data laid out in
-exactly the same way. However Rust *does not* guarantee that an instance of A
-has the same field ordering or padding as an instance of B (in practice there's
-no particular reason why they wouldn't, other than that its not currently
-guaranteed).
+exactly the same way. However Rust *does not* currently guarantee that an
+instance of A has the same field ordering or padding as an instance of B, though
+in practice there's no reason why they wouldn't.
 
-With A and B as written, this is basically nonsensical, but several other
+With A and B as written, this point would seem to be pedantic, but several other
 features of Rust make it desirable for the language to play with data layout in
 complex ways.
 
@@ -133,18 +132,21 @@ struct FooRepr {
 }
 ```
 
-And indeed this is approximately how it would be laid out in general
-(modulo the size and position of `tag`). However there are several cases where
-such a representation is inefficient. The classic case of this is Rust's
-"null pointer optimization". Given a pointer that is known to not be null
-(e.g. `&u32`), an enum can *store* a discriminant bit *inside* the pointer
-by using null as a special value. The net result is that
-`size_of::<Option<&T>>() == size_of::<&T>()`
+And indeed this is approximately how it would be laid out in general (modulo the
+size and position of `tag`).
+
+However there are several cases where such a representation is inefficient. The
+classic case of this is Rust's "null pointer optimization": an enum consisting
+of a single outer unit variant (e.g. `None`) and a (potentially nested) non-
+nullable pointer variant (e.g. `&T`) makes the tag unnecessary, because a null
+pointer value can safely be interpreted to mean that the unit variant is chosen
+instead. The net result is that, for example, `size_of::<Option<&T>>() ==
+size_of::<&T>()`.
 
-There are many types in Rust that are, or contain, "not null" pointers such as
+There are many types in Rust that are, or contain, non-nullable pointers such as
 `Box<T>`, `Vec<T>`, `String`, `&T`, and `&mut T`. Similarly, one can imagine
 nested enums pooling their tags into a single discriminant, as they are by
-definition known to have a limited range of valid values. In principle enums can
+definition known to have a limited range of valid values. In principle enums could
 use fairly elaborate algorithms to cache bits throughout nested types with
 special constrained representations. As such it is *especially* desirable that
 we leave enum layout unspecified today.

branches/try/src/doc/reference.md

@@ -1501,7 +1501,29 @@ have an implementation for `Shape`. Multiple supertraits are separated by `+`,
 `trait Circle : Shape + PartialEq { }`. In an implementation of `Circle` for a
 given type `T`, methods can refer to `Shape` methods, since the typechecker
 checks that any type with an implementation of `Circle` also has an
-implementation of `Shape`.
+implementation of `Shape`:
+
+```rust
+struct Foo;
+
+trait Shape { fn area(&self) -> f64; }
+trait Circle : Shape { fn radius(&self) -> f64; }
+# impl Shape for Foo {
+#     fn area(&self) -> f64 {
+#         0.0
+#     }
+# }
+impl Circle for Foo {
+    fn radius(&self) -> f64 {
+        println!("calling area: {}", self.area());
+
+        0.0
+    }
+}
+
+let c = Foo;
+c.radius();
+```
 
 In type-parameterized functions, methods of the supertrait may be called on
 values of subtrait-bound type parameters. Referring to the previous example of

branches/try/src/doc/trpl/advanced-linking.md

@@ -38,12 +38,12 @@ Static linking refers to the process of creating output that contain all
 required libraries and so don't need libraries installed on every system where
 you want to use your compiled project. Pure-Rust dependencies are statically
 linked by default so you can use created binaries and libraries without
-installing the Rust everywhere. By contrast, native libraries
-(e.g. `libc` and `libm`) usually dynamically linked, but it is possible to
+installing Rust everywhere. By contrast, native libraries
+(e.g. `libc` and `libm`) are usually dynamically linked, but it is possible to
 change this and statically link them as well.
 
-Linking is a very platform dependent topic — on some platforms, static linking
-may not be possible at all! This section assumes some basic familiarity with
+Linking is a very platform-dependent topic, and static linking may not even be
+possible on some platforms! This section assumes some basic familiarity with
 linking on your platform of choice.
 
 ## Linux
@@ -71,8 +71,7 @@ Dynamic linking on Linux can be undesirable if you wish to use new library
 features on old systems or target systems which do not have the required
 dependencies for your program to run.
 
-Static linking is supported via an alternative `libc`, `musl` - this must be
-enabled at Rust compile-time with some prerequisites available. You can compile
+Static linking is supported via an alternative `libc`, `musl`. You can compile
 your own version of Rust with `musl` enabled and install it into a custom
 directory with the instructions below:
 
@@ -123,7 +122,7 @@ $ du -h musldist/bin/rustc
 ```
 
 You now have a build of a `musl`-enabled Rust! Because we've installed it to a
-custom prefix we need to make sure our system can the binaries and appropriate
+custom prefix we need to make sure our system can find the binaries and appropriate
 libraries when we try and run it:
 
 ```text

branches/try/src/doc/trpl/closures.md

@@ -316,6 +316,35 @@ assert_eq!(3, answer);
 Now we take a trait object, a `&Fn`. And we have to make a reference
 to our closure when we pass it to `call_with_one`, so we use `&||`.
 
+# Function pointers and closures
+
+A function pointer is kind of like a closure that has no environment. As such,
+you can pass a function pointer to any function expecting a closure argument,
+and it will work:
+
+```rust
+fn call_with_one(some_closure: &Fn(i32) -> i32) -> i32 {
+    some_closure(1)
+}
+
+fn add_one(i: i32) -> i32 {
+    i + 1
+}
+
+let f = add_one;
+
+let answer = call_with_one(&f);
+
+assert_eq!(2, answer);
+```
+
+In this example, we don’t strictly need the intermediate variable `f`,
+the name of the function works just fine too:
+
+```ignore
+let answer = call_with_one(&add_one);
+```
+
 # Returning closures
 
 It’s very common for functional-style code to return closures in various

branches/try/src/doc/trpl/functions.md

@@ -227,3 +227,34 @@ as any type:
 let x: i32 = diverges();
 let x: String = diverges();
 ```
+
+## Function pointers
+
+We can also create variable bindings which point to functions:
+
+```rust
+let f: fn(i32) -> i32;
+```
+
+`f` is a variable binding which points to a function that takes an `i32` as
+an argument and returns an `i32`. For example:
+
+```rust
+fn plus_one(i: i32) -> i32 {
+    i + 1
+}
+
+// without type inference
+let f: fn(i32) -> i32 = plus_one;
+
+// with type inference
+let f = plus_one;
+```
+
+We can then use `f` to call the function:
+
+```rust
+# fn plus_one(i: i32) -> i32 { i + 1 }
+# let f = plus_one;
+let six = f(5);
+```

branches/try/src/doc/trpl/generics.md

@@ -6,7 +6,7 @@ Generics are called ‘parametric polymorphism’ in type theory,
 which means that they are types or functions that have multiple forms (‘poly’
 is multiple, ‘morph’ is form) over a given parameter (‘parametric’).
 
-Anyway, enough with type theory, let’s check out some generic code. Rust’s
+Anyway, enough type theory, let’s check out some generic code. Rust’s
 standard library provides a type, `Option<T>`, that’s generic:
 
 ```rust
@@ -27,7 +27,7 @@ let x: Option<i32> = Some(5);
 
 In the type declaration, we say `Option<i32>`. Note how similar this looks to
 `Option<T>`. So, in this particular `Option`, `T` has the value of `i32`. On
-the right-hand side of the binding, we do make a `Some(T)`, where `T` is `5`.
+the right-hand side of the binding, we make a `Some(T)`, where `T` is `5`.
 Since that’s an `i32`, the two sides match, and Rust is happy. If they didn’t
 match, we’d get an error:
 
@@ -101,11 +101,6 @@ fn takes_two_things<T, U>(x: T, y: U) {
 }
 ```
 
-Generic functions are most useful with ‘trait bounds’, which we’ll cover in the
-[section on traits][traits].
-
-[traits]: traits.html
-
 ## Generic structs
 
 You can store a generic type in a `struct` as well:
@@ -122,3 +117,28 @@ let float_origin = Point { x: 0.0, y: 0.0 };
 
 Similarly to functions, the `<T>` is where we declare the generic parameters,
 and we then use `x: T` in the type declaration, too.
+
+When you want to add an implementation for the generic struct, you just
+declare the type parameter after the `impl`:
+
+```rust
+# struct Point<T> {
+#     x: T,
+#     y: T,
+# }
+#
+impl<T> Point<T> {
+    fn swap(&mut self) {
+        std::mem::swap(&mut self.x, &mut self.y);
+    }
+}
+```
+
+So far you’ve seen generics that take absolutely any type. These are useful in
+many cases: you’ve already seen `Option<T>`, and later you’ll meet universal
+container types like [`Vec<T>`][Vec]. On the other hand, often you want to
+trade that flexibility for increased expressive power. Read about [trait
+bounds][traits] to see why and how.
+
+[traits]: traits.html
+[Vec]: ../std/vec/struct.Vec.html

branches/try/src/doc/trpl/guessing-game.md

@@ -533,7 +533,7 @@ Great! Next up: let’s compare our guess to the secret guess.
 # Comparing guesses
 
 Now that we’ve got user input, let’s compare our guess to the random guess.
-Here’s our next step, though it doesn’t quite work yet:
+Here’s our next step, though it doesn’t quite compile yet:
 
 ```rust,ignore
 extern crate rand;
@@ -617,7 +617,7 @@ match guess.cmp(&secret_number) {
 If it’s `Less`, we print `Too small!`, if it’s `Greater`, `Too big!`, and if
 `Equal`, `You win!`. `match` is really useful, and is used often in Rust.
 
-I did mention that this won’t quite work yet, though. Let’s try it:
+I did mention that this won’t quite compile yet, though. Let’s try it:
 
 ```bash
 $ cargo build

branches/try/src/doc/trpl/lifetimes.md

@@ -77,8 +77,18 @@ Before we get to that, though, let’s break the explicit example down:
 fn bar<'a>(...)
 ```
 
-This part declares our lifetimes. This says that `bar` has one lifetime, `'a`.
-If we had two reference parameters, it would look like this:
+We previously talked a little about [function syntax][functions], but we didn’t
+discuss the `<>`s after a function’s name. A function can have ‘generic
+parameters’ between the `<>`s, of which lifetimes are one kind. We’ll discuss
+other kinds of generics [later in the book][generics], but for now, let’s
+just focus on the lifetimes aspect.
+
+[functions]: functions.html
+[generics]: generics.html
+
+We use `<>` to declare our lifetimes. This says that `bar` has one lifetime,
+`'a`. If we had two reference parameters, it would look like this:
+
 
 ```rust,ignore
 fn bar<'a, 'b>(...)