---

yaml
---
r: 223218
b: refs/heads/auto
c: fd142bb
h: refs/heads/master
v: v3

Author: brson

[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: 68f79288bf1ac2b014277750cbf59416c91f7d04
+refs/heads/auto: fd142bb741848236d4ab3a7655e58014d29889da
 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)
-may return `nullptr` when a zero-sized allocation is requested, which is
-indistinguishable from out of memory.
+generally consider passing in `0` for the size of an allocation as Undefined
+Behaviour.
 
 
 

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

@@ -36,9 +36,9 @@ struct A {
 }
 ```
 
-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:
+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:
 
 ```rust
 struct A {
@@ -50,10 +50,10 @@ struct A {
 }
 ```
 
-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:
+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:
 
 ```rust
 struct A {
@@ -62,17 +62,18 @@ struct A {
 }
 
 struct B {
-    a: i32,
+    x: 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* 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.
+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).
 
-With A and B as written, this point would seem to be pedantic, but several other
+With A and B as written, this is basically nonsensical, but several other
 features of Rust make it desirable for the language to play with data layout in
 complex ways.
 
@@ -132,21 +133,18 @@ 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": 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>()`.
+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>()`
 
-There are many types in Rust that are, or contain, non-nullable pointers such as
+There are many types in Rust that are, or contain, "not null" 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 could
+definition known to have a limited range of valid values. In principle enums can
 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,29 +1501,7 @@ 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`:
-
-```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();
-```
+implementation of `Shape`.
 
 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,35 +316,6 @@ 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,34 +227,3 @@ 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 type theory, let’s check out some generic code. Rust’s
+Anyway, enough with 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 make a `Some(T)`, where `T` is `5`.
+the right-hand side of the binding, we do 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,6 +101,11 @@ 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:
@@ -117,28 +122,3 @@ 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 compile yet:
+Here’s our next step, though it doesn’t quite work 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 compile yet, though. Let’s try it:
+I did mention that this won’t quite work yet, though. Let’s try it:
 
 ```bash
 $ cargo build

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

@@ -77,18 +77,8 @@ Before we get to that, though, let’s break the explicit example down:
 fn bar<'a>(...)
 ```
 
-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:
-
+This part declares 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,55 +81,3 @@ 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,10 +125,6 @@ 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