---

yaml
---
r: 223214
b: refs/heads/auto
c: 11deb08
h: refs/heads/master
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: 83e43bb728b95d52039824d63b1ba5bbde5c5d7b
+refs/heads/auto: 11deb083f5bc3e57e73fc82de4bef7b1d4dad7b1
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336
 refs/tags/0.2: 1754d02027f2924bed83b0160ee340c7f41d5ea1

branches/auto/mk/main.mk

@@ -13,7 +13,7 @@
 ######################################################################
 
 # The version number
-CFG_RELEASE_NUM=1.3.0
+CFG_RELEASE_NUM=1.4.0
 
 # An optional number to put after the label, e.g. '.2' -> '-beta.2'
 # NB Make sure it starts with a dot to conform to semver pre-release

branches/auto/src/doc/nomicon/atomics.md

@@ -127,7 +127,7 @@ fundamentally unsynchronized and compilers are free to aggressively optimize
 them. In particular, data accesses are free to be reordered by the compiler on
 the assumption that the program is single-threaded. The hardware is also free to
 propagate the changes made in data accesses to other threads as lazily and
-inconsistently as it wants. Mostly critically, data accesses are how data races
+inconsistently as it wants. Most critically, data accesses are how data races
 happen. Data accesses are very friendly to the hardware and compiler, but as
 we've seen they offer *awful* semantics to try to write synchronized code with.
 Actually, that's too weak.

branches/auto/src/doc/nomicon/concurrency.md

@@ -7,7 +7,7 @@ an abstraction over them in a relatively uncontroversial way. Message passing,
 green threads, and async APIs are all diverse enough that any abstraction over
 them tends to involve trade-offs that we weren't willing to commit to for 1.0.
 
-However the way Rust models concurrency makes it relatively easy design your own
+However the way Rust models concurrency makes it relatively easy to design your own
 concurrency paradigm as a library and have everyone else's code Just Work
 with yours. Just require the right lifetimes and Send and Sync where appropriate
 and you're off to the races. Or rather, off to the... not... having... races.

branches/auto/src/doc/nomicon/destructors.md

@@ -120,7 +120,7 @@ enum Link {
 will have its inner Box field dropped if and only if an instance stores the
 Next variant.
 
-In general this works really nice because you don't need to worry about
+In general this works really nicely because you don't need to worry about
 adding/removing drops when you refactor your data layout. Still there's
 certainly many valid usecases for needing to do trickier things with
 destructors.

branches/auto/src/doc/nomicon/drop-flags.md

@@ -1,7 +1,7 @@
 % Drop Flags
 
 The examples in the previous section introduce an interesting problem for Rust.
-We have seen that's possible to conditionally initialize, deinitialize, and
+We have seen that it's possible to conditionally initialize, deinitialize, and
 reinitialize locations of memory totally safely. For Copy types, this isn't
 particularly notable since they're just a random pile of bits. However types
 with destructors are a different story: Rust needs to know whether to call a

branches/auto/src/doc/nomicon/dropck.md

@@ -1,7 +1,7 @@
 % Drop Check
 
 We have seen how lifetimes provide us some fairly simple rules for ensuring
-that never read dangling references. However up to this point we have only ever
+that we never read dangling references. However up to this point we have only ever
 interacted with the *outlives* relationship in an inclusive manner. That is,
 when we talked about `'a: 'b`, it was ok for `'a` to live *exactly* as long as
 `'b`. At first glance, this seems to be a meaningless distinction. Nothing ever

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/nomicon/send-and-sync.md

@@ -3,15 +3,15 @@
 Not everything obeys inherited mutability, though. Some types allow you to
 multiply alias a location in memory while mutating it. Unless these types use
 synchronization to manage this access, they are absolutely not thread safe. Rust
-captures this with through the `Send` and `Sync` traits.
+captures this through the `Send` and `Sync` traits.
 
 * A type is Send if it is safe to send it to another thread.
 * A type is Sync if it is safe to share between threads (`&T` is Send).
 
 Send and Sync are fundamental to Rust's concurrency story. As such, a
 substantial amount of special tooling exists to make them work right. First and
 foremost, they're [unsafe traits][]. This means that they are unsafe to
-implement, and other unsafe code can  that they are correctly
+implement, and other unsafe code can assume that they are correctly
 implemented. Since they're *marker traits* (they have no associated items like
 methods), correctly implemented simply means that they have the intrinsic
 properties an implementor should have. Incorrectly implementing Send or Sync can

branches/auto/src/doc/nomicon/subtyping.md

@@ -93,8 +93,8 @@ fn main() {
 
 The signature of `overwrite` is clearly valid: it takes mutable references to
 two values of the same type, and overwrites one with the other. If `&mut T` was
-variant over T, then `&mut &'a str` would be a subtype of `&mut &'static str`,
-since `&'a str` is a subtype of `&'static str`. Therefore the lifetime of
+variant over T, then `&mut &'static str` would be a subtype of `&mut &'a str`,
+since `&'static str` is a subtype of `&'a str`. Therefore the lifetime of
 `forever_str` would successfully be "shrunk" down to the shorter lifetime of
 `string`, and `overwrite` would be called successfully. `string` would
 subsequently be dropped, and `forever_str` would point to freed memory when we

branches/auto/src/doc/nomicon/unchecked-uninit.md

@@ -77,7 +77,7 @@ contain any `Drop` types.
 However when working with uninitialized memory you need to be ever-vigilant for
 Rust trying to drop values you make like this before they're fully initialized.
 Every control path through that variable's scope must initialize the value
-before it ends, if has a destructor.
+before it ends, if it has a destructor.
 *[This includes code panicking](unwinding.html)*.
 
 And that's about it for working with uninitialized memory! Basically nothing

branches/auto/src/doc/reference.md

@@ -538,8 +538,9 @@ balanced, but they are otherwise not special.
 In the matcher, `$` _name_ `:` _designator_ matches the nonterminal in the Rust
 syntax named by _designator_. Valid designators are `item`, `block`, `stmt`,
 `pat`, `expr`, `ty` (type), `ident`, `path`, `tt` (either side of the `=>`
-in macro rules). In the transcriber, the designator is already known, and so
-only the name of a matched nonterminal comes after the dollar sign.
+in macro rules), and `meta` (contents of an attribute). In the transcriber, the
+designator is already known, and so only the name of a matched nonterminal comes
+after the dollar sign.
 
 In both the matcher and transcriber, the Kleene star-like operator indicates
 repetition. The Kleene star operator consists of `$` and parentheses, optionally
@@ -1500,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