---

yaml
---
r: 183551
b: refs/heads/beta
c: a7d5c3f
h: refs/heads/master
i:
  183549: 9e3d148
  183547: c2ad2d0
  183543: 4d324d1
  183535: d9f98c2
  183519: a06998a
  183487: acf4a4b
  183423: f85bdc0
  183295: 5b3adb0
v: v3

Author: pnkfelix

[refs]

@@ -31,7 +31,7 @@ refs/heads/automation-fail: 1bf06495443584539b958873e04cc2f864ab10e4
 refs/heads/issue-18208-method-dispatch-3-quick-reject: 2009f85b9f99dedcec4404418eda9ddba90258a2
 refs/heads/batch: b7fd822592a4fb577552d93010c4a4e14f314346
 refs/heads/building: 126db549b038c84269a1e4fe46f051b2c15d6970
-refs/heads/beta: f96fb8ecb82bdab279f955a44fdb80e309815c6c
+refs/heads/beta: a7d5c3f682002157c9d74cce773fb792d92333e1
 refs/heads/windistfix: 7608dbad651f02e837ed05eef3d74a6662a6e928
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
 refs/heads/tmp: eb836bf767aa1d8d4cba488a9091cde3c0ab4b2f

branches/beta/configure

@@ -1379,8 +1379,7 @@ do
 done
 
 # Munge any paths that appear in config.mk back to posix-y
-cp config.tmp config.tmp.bak
-sed -e 's@ \([a-zA-Z]\):[/\\]@ /\1/@g;' <config.tmp.bak >config.tmp
+sed -i.bak -e 's@ \([a-zA-Z]\):[/\\]@ /\1/@g;' config.tmp
 rm -f config.tmp.bak
 
 msg

branches/beta/mk/main.mk

@@ -61,16 +61,13 @@ SPACE :=
 SPACE +=
 ifneq ($(CFG_GIT),)
 ifneq ($(wildcard $(subst $(SPACE),\$(SPACE),$(CFG_GIT_DIR))),)
-    CFG_VER_DATE = $(shell git --git-dir='$(CFG_GIT_DIR)' log -1 --date=short --pretty=format:'%cd')
+    CFG_VER_DATE = $(shell git --git-dir='$(CFG_GIT_DIR)' log -1 --pretty=format:'%ci')
     CFG_VER_HASH = $(shell git --git-dir='$(CFG_GIT_DIR)' rev-parse HEAD)
     CFG_SHORT_VER_HASH = $(shell git --git-dir='$(CFG_GIT_DIR)' rev-parse --short=9 HEAD)
     CFG_VERSION += ($(CFG_SHORT_VER_HASH) $(CFG_VER_DATE))
 endif
 endif
 
-CFG_BUILD_DATE = $(shell date +%F)
-CFG_VERSION += (built $(CFG_BUILD_DATE))
-
 # Windows exe's need numeric versions - don't use anything but
 # numbers and dots here
 CFG_VERSION_WIN = $(CFG_RELEASE_NUM)
@@ -320,7 +317,6 @@ endif
 ifdef CFG_VER_HASH
 export CFG_VER_HASH
 endif
-export CFG_BUILD_DATE
 export CFG_VERSION
 export CFG_VERSION_WIN
 export CFG_RELEASE

branches/beta/src/doc/complement-bugreport.md

@@ -56,6 +56,8 @@ $ RUST_BACKTRACE=1 rustc ...
 
 # I submitted a bug, but nobody has commented on it!
 
-This is sad, but does happen sometimes, since we're short-staffed. If you submit a
-bug and you haven't received a comment on it within 3 business days, it's entirely
-reasonable to ask about the status of the bug in #rust on irc.mozilla.org.
+This is sad, but does happen sometimes, since we're short-staffed. If you
+submit a bug and you haven't received a comment on it within 3 business days,
+it's entirely reasonable to either ask on the #rust IRC channel,
+or post on the [rust-dev mailing list](https://mail.mozilla.org/listinfo/rust-dev)
+to ask what the status of the bug is.

branches/beta/src/doc/intro.md

@@ -224,7 +224,7 @@ segfault when we allocate more memory?
 
 The answer is that in the C++ version, `x` is a *reference* to the memory
 location where the first element of the array is stored. But in Ruby, `x` is a
-standalone value, not connected to the underlying array at all. Let's dig into
+standalone value, not connected to the underyling array at all. Let's dig into
 the details for a moment. Your program has access to memory, provided to it by
 the operating system. Each location in memory has an address.  So when we make
 our vector, `v`, it's stored in a memory location somewhere:

branches/beta/src/doc/reference.md

@@ -2377,21 +2377,33 @@ considered off, and using the features will result in a compiler error.
 
 The currently implemented features of the reference compiler are:
 
+* `advanced_slice_patterns` - see the [match expressions](#match-expressions)
+                              section for discussion; the exact semantics of
+                              slice patterns are subject to change.
+
 * `asm` - The `asm!` macro provides a means for inline assembly. This is often
           useful, but the exact syntax for this feature along with its
           semantics are likely to change, so this macro usage must be opted
           into.
 
+* `associated_types` - Allows type aliases in traits. Experimental.
+
+* `box_patterns` - Allows `box` patterns, the exact semantics of which
+                   is subject to change.
+
+* `box_syntax` - Allows use of `box` expressions, the exact semantics of which
+                 is subject to change.
+
 * `concat_idents` - Allows use of the `concat_idents` macro, which is in many
                     ways insufficient for concatenating identifiers, and may be
                     removed entirely for something more wholesome.
 
-* `default_type_params` - Allows use of default type parameters. The future of
-                          this feature is uncertain.
-
 * `intrinsics` - Allows use of the "rust-intrinsics" ABI. Compiler intrinsics
                  are inherently unstable and no promise about them is made.
 
+* `int_uint` - Allows the use of the `int` and `uint` types, which are deprecated.
+               Use `isize` and `usize` instead.
+
 * `lang_items` - Allows use of the `#[lang]` attribute. Like `intrinsics`,
                  lang items are inherently unstable and no promise about them
                  is made.
@@ -2410,12 +2422,33 @@ The currently implemented features of the reference compiler are:
 * `log_syntax` - Allows use of the `log_syntax` macro attribute, which is a
                  nasty hack that will certainly be removed.
 
+* `main` - Allows use of the `#[main]` attribute, which changes the entry point
+           into a Rust program. This capabiilty is subject to change.
+
+* `macro_reexport` - Allows macros to be re-exported from one crate after being imported
+                     from another. This feature was originally designed with the sole
+                     use case of the Rust standard library in mind, and is subject to
+                     change.
+
 * `non_ascii_idents` - The compiler supports the use of non-ascii identifiers,
                        but the implementation is a little rough around the
                        edges, so this can be seen as an experimental feature
                        for now until the specification of identifiers is fully
                        fleshed out.
 
+* `no_std` - Allows the `#![no_std]` crate attribute, which disables the implicit
+             `extern crate std`. This typically requires use of the unstable APIs
+             behind the libstd "facade", such as libcore and libcollections. It
+             may also cause problems when using syntax extensions, including
+             `#[derive]`.
+
+* `on_unimplemented` - Allows the `#[rustc_on_unimplemented]` attribute, which allows
+                       trait definitions to add specialized notes to error messages
+                       when an implementation was expected but not found.
+
+* `optin_builtin_traits` - Allows the definition of default and negative trait
+                           implementations. Experimental.
+
 * `plugin` - Usage of [compiler plugins][plugin] for custom lints or syntax extensions.
              These depend on compiler internals and are subject to change.
 
@@ -2431,8 +2464,15 @@ The currently implemented features of the reference compiler are:
 * `simd` - Allows use of the `#[simd]` attribute, which is overly simple and
            not the SIMD interface we want to expose in the long term.
 
+* `simd_ffi` - Allows use of SIMD vectors in signatures for foreign functions.
+               The SIMD interface is subject to change.
+
 * `staged_api` - Allows usage of stability markers and `#![staged_api]` in a crate
 
+* `start` - Allows use of the `#[start]` attribute, which changes the entry point
+            into a Rust program. This capabiilty, especially the signature for the
+            annotated function, is subject to change.
+
 * `struct_inherit` - Allows using struct inheritance, which is barely
                      implemented and will probably be removed. Don't use this.
 
@@ -2460,18 +2500,20 @@ The currently implemented features of the reference compiler are:
                         which is considered wildly unsafe and will be
                         obsoleted by language improvements.
 
+* `unsafe_no_drop_flag` - Allows use of the `#[unsafe_no_drop_flag]` attribute,
+                          which removes hidden flag added to a type that
+                          implements the `Drop` trait. The design for the
+                          `Drop` flag is subject to change, and this feature
+                          may be removed in the future.
+
 * `unmarked_api` - Allows use of items within a `#![staged_api]` crate
                    which have not been marked with a stability marker.
                    Such items should not be allowed by the compiler to exist,
                    so if you need this there probably is a compiler bug.
 
-* `associated_types` - Allows type aliases in traits. Experimental.
-
-* `no_std` - Allows the `#![no_std]` crate attribute, which disables the implicit
-             `extern crate std`. This typically requires use of the unstable APIs
-             behind the libstd "facade", such as libcore and libcollections. It
-             may also cause problems when using syntax extensions, including
-             `#[derive]`.
+* `visible_private_types` - Allows public APIs to expose otherwise private
+                            types, e.g. as the return type of a public function.
+                            This capability may be removed in the future.
 
 If a feature is promoted to a language feature, then all existing programs will
 start to receive compilation warnings about #[feature] directives which enabled
@@ -2591,8 +2633,9 @@ of any reference that points to it.
 
 When a [local variable](#memory-slots) is used as an
 [rvalue](#lvalues,-rvalues-and-temporaries) the variable will either be moved
-or copied, depending on its type. All values whose type implements `Copy` are
-copied, all others are moved.
+or copied, depending on its type. For types that contain [owning
+pointers](#pointer-types) or values that implement the special trait `Drop`,
+the variable is moved. All other types are copied.
 
 ### Literal expressions
 
@@ -3004,7 +3047,7 @@ Some examples of call expressions:
 # fn add(x: i32, y: i32) -> i32 { 0 }
 
 let x: i32 = add(1i32, 2i32);
-let pi: Result<f32, _> = "3.14".parse();
+let pi: Option<f32> = "3.14".parse().ok();
 ```
 
 ### Lambda expressions
@@ -3147,7 +3190,7 @@ An example of a for loop over a series of integers:
 
 ```
 # fn bar(b:usize) { }
-for i in 0us..256 {
+for i in range(0us, 256) {
     bar(i);
 }
 ```
@@ -3531,7 +3574,7 @@ An example of each kind:
 ```{rust}
 let vec: Vec<i32> = vec![1, 2, 3];
 let arr: [i32; 3] = [1, 2, 3];
-let s: &[i32] = &vec[];
+let s: &[i32] = &vec;
 ```
 
 As you can see, the `vec!` macro allows you to create a `Vec<T>` easily. The

branches/beta/src/doc/trpl/compound-data-types.md

@@ -263,12 +263,15 @@ let four_is_smaller = four <= ten;
 let four_equals_ten = four == ten;
 ```
 
-This may seem rather limiting, but it's a limitation which we can overcome.
-There are two ways: by implementing equality ourselves, or by using the
-[`match`][match] keyword. We don't know enough about Rust to implement equality
-yet, but we can use the `Ordering` enum from the standard library, which does:
+This may seem rather limiting, particularly equality being invalid; in
+many cases however, it's unnecessary. Rust provides the [`match`][match]
+keyword, which will be examined in more detail in the next section, which
+often allows better and easier branch control than a series of `if`/`else`
+statements would. However, for our [game][game] we need the comparisons
+to work so we will utilize the `Ordering` `enum` provided by the standard
+library which supports such comparisons. It has this form:
 
-```
+```{rust}
 enum Ordering {
     Less,
     Equal,

branches/beta/src/doc/trpl/concurrency.md

@@ -354,7 +354,7 @@ use std::sync::mpsc;
 fn main() {
     let (tx, rx) = mpsc::channel();
 
-    for _ in 0..10 {
+    for _ in range(0, 10) {
         let tx = tx.clone();
 
         Thread::spawn(move || {

branches/beta/src/doc/trpl/documentation.md

@@ -1,4 +1,4 @@
-% Documentation
+% Rust Documentation
 
 `rustdoc` is the built-in tool for generating documentation. It integrates
 with the compiler to provide accurate hyperlinking between usage of types and
@@ -294,26 +294,3 @@ Documentation` on the first line).
 Like with a Rust crate, the `--test` argument will run the code
 examples to check they compile, and obeys any `--test-args` flags. The
 tests are named after the last `#` heading.
-
-# Re-exports
-
-Rustdoc will show the documentation for a publc re-export in both places:
-
-```{rust,ignore}
-extern crate foo;
-
-pub use foo::bar;
-```
-
-This will create documentation for `bar` both inside the documentation for
-the crate `foo`, as well as the documentation for your crate. It will use
-the same documentation in both places.
-
-This behavior can be supressed with `no_inline`:
-
-```{rust,ignore}
-extern crate foo;
-
-#[doc(no_inline)]
-pub use foo::bar;
-```