---

yaml
---
r: 223219
b: refs/heads/auto
c: 1181679
h: refs/heads/master
i:
  223217: 9ed8be8
  223215: e593829
v: v3

Author: bors

[refs]

@@ -8,7 +8,7 @@ refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: fd142bb741848236d4ab3a7655e58014d29889da
+refs/heads/auto: 1181679c8f84f8ca1c70b60d63ee88336ac363dd
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336
 refs/tags/0.2: 1754d02027f2924bed83b0160ee340c7f41d5ea1

branches/auto/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/auto/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/auto/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/auto/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/auto/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/auto/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/auto/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/auto/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 lifteimes 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>(...)

branches/auto/src/doc/trpl/operators-and-overloading.md

@@ -81,3 +81,55 @@ will let you do this:
 let p: Point = // ...
 let x: f64 = p + 2i32;
 ```
+
+# Using operator traits in generic structs
+
+Now that we know how operator traits are defined, we can define our `HasArea`
+trait and `Square` struct from the [traits chapter][traits] more generically:
+
+[traits]: traits.html
+
+```rust
+use std::ops::Mul;
+
+trait HasArea<T> {
+    fn area(&self) -> T;
+}
+
+struct Square<T> {
+    x: T,
+    y: T,
+    side: T,
+}
+
+impl<T> HasArea<T> for Square<T>
+        where T: Mul<Output=T> + Copy {
+    fn area(&self) -> T {
+        self.side * self.side
+    }
+}
+
+fn main() {
+    let s = Square {
+        x: 0.0f64,
+        y: 0.0f64,
+        side: 12.0f64,
+    };
+
+    println!("Area of s: {}", s.area());
+}
+```
+
+For `HasArea` and `Square`, we just declare a type parameter `T` and replace
+`f64` with it. The `impl` needs more involved modifications:
+
+```ignore
+impl<T> HasArea<T> for Square<T>
+        where T: Mul<Output=T> + Copy { ... }
+```
+
+The `area` method requires that we can multiply the sides, so we declare that
+type `T` must implement `std::ops::Mul`. Like `Add`, mentioned above, `Mul`
+itself takes an `Output` parameter: since we know that numbers don't change
+type when multiplied, we also set it to `T`. `T` must also support copying, so
+Rust doesn't try to move `self.side` into the return value.

branches/auto/src/doc/trpl/references-and-borrowing.md

@@ -125,6 +125,10 @@ This will print `6`. We make `y` a mutable reference to `x`, then add one to
 the thing `y` points at. You’ll notice that `x` had to be marked `mut` as well,
 if it wasn’t, we couldn’t take a mutable borrow to an immutable value.
 
+You'll also notice we added an asterisk (`*`) in front of `y`, making it `*y`,
+this is because `y` is an `&mut` reference. You'll also need to use them for
+accessing the contents of a reference as well.
+
 Otherwise, `&mut` references are just like references. There _is_ a large
 difference between the two, and how they interact, though. You can tell
 something is fishy in the above example, because we need that extra scope, with