---

yaml
---
r: 172205
b: refs/heads/beta
c: 4d98cbb
h: refs/heads/master
i:
  172203: ca3fec8
v: v3

Author: nrc

[refs]

@@ -31,5 +31,5 @@ refs/heads/automation-fail: 1bf06495443584539b958873e04cc2f864ab10e4
 refs/heads/issue-18208-method-dispatch-3-quick-reject: 2009f85b9f99dedcec4404418eda9ddba90258a2
 refs/heads/batch: b5571ed71a5879c0495a982506258d5d267744ed
 refs/heads/building: 126db549b038c84269a1e4fe46f051b2c15d6970
-refs/heads/beta: 0dc48b47a8c67eb28e7b89a6c0810dc9446377f7
+refs/heads/beta: 4d98cbb3f3692c1fd53cd27a45a9bb1e813be942
 refs/heads/windistfix: 7608dbad651f02e837ed05eef3d74a6662a6e928

branches/beta/configure

@@ -599,18 +599,6 @@ then
 fi
 putvar CFG_RELEASE_CHANNEL
 
-# A magic value that allows the compiler to use unstable features
-# during the bootstrap even when doing so would normally be an error
-# because of feature staging or because the build turns on
-# warnings-as-errors and unstable features default to warnings.  The
-# build has to match this key in an env var. Meant to be a mild
-# deterrent from users just turning on unstable features on the stable
-# channel.
-# Basing CFG_BOOTSTRAP_KEY on CFG_BOOTSTRAP_KEY lets it get picked up
-# during a Makefile reconfig.
-CFG_BOOTSTRAP_KEY="${CFG_BOOTSTRAP_KEY-`date +%N`}"
-putvar CFG_BOOTSTRAP_KEY
-
 step_msg "looking for build programs"
 
 probe_need CFG_PERL        perl

branches/beta/mk/main.mk

@@ -25,13 +25,11 @@ ifeq ($(CFG_RELEASE_CHANNEL),stable)
 CFG_RELEASE=$(CFG_RELEASE_NUM)
 # This is the string used in dist artifact file names, e.g. "0.12.0", "nightly"
 CFG_PACKAGE_VERS=$(CFG_RELEASE_NUM)
-CFG_DISABLE_UNSTABLE_FEATURES=1
 endif
 ifeq ($(CFG_RELEASE_CHANNEL),beta)
 # The beta channel is temporarily called 'alpha'
 CFG_RELEASE=$(CFG_RELEASE_NUM)-alpha$(CFG_BETA_CYCLE)
 CFG_PACKAGE_VERS=$(CFG_RELEASE_NUM)-alpha$(CFG_BETA_CYCLE)
-CFG_DISABLE_UNSTABLE_FEATURES=1
 endif
 ifeq ($(CFG_RELEASE_CHANNEL),nightly)
 CFG_RELEASE=$(CFG_RELEASE_NUM)-nightly
@@ -123,9 +121,11 @@ CFG_JEMALLOC_FLAGS += $(JEMALLOC_FLAGS)
 
 ifdef CFG_DISABLE_DEBUG
   CFG_RUSTC_FLAGS += --cfg ndebug
+  CFG_GCCISH_CFLAGS += -DRUST_NDEBUG
 else
   $(info cfg: enabling more debugging (CFG_ENABLE_DEBUG))
   CFG_RUSTC_FLAGS += --cfg debug
+  CFG_GCCISH_CFLAGS += -DRUST_DEBUG
 endif
 
 ifdef SAVE_TEMPS
@@ -319,20 +319,11 @@ export CFG_VERSION_WIN
 export CFG_RELEASE
 export CFG_PACKAGE_NAME
 export CFG_BUILD
-export CFG_RELEASE_CHANNEL
 export CFG_LLVM_ROOT
 export CFG_PREFIX
 export CFG_LIBDIR
 export CFG_LIBDIR_RELATIVE
 export CFG_DISABLE_INJECT_STD_VERSION
-ifdef CFG_DISABLE_UNSTABLE_FEATURES
-CFG_INFO := $(info cfg: disabling unstable features (CFG_DISABLE_UNSTABLE_FEATURES))
-# Turn on feature-staging
-export CFG_DISABLE_UNSTABLE_FEATURES
-endif
-# Subvert unstable feature lints to do the self-build
-export CFG_BOOTSTRAP_KEY
-export RUSTC_BOOTSTRAP_KEY:=$(CFG_BOOTSTRAP_KEY)
 
 ######################################################################
 # Per-stage targets and runner

branches/beta/src/compiletest/compiletest.rs

@@ -9,9 +9,7 @@
 // except according to those terms.
 
 #![crate_type = "bin"]
-#![allow(unknown_features)]
 #![feature(slicing_syntax, unboxed_closures)]
-#![feature(box_syntax)]
 
 #![deny(warnings)]
 

branches/beta/src/compiletest/runtest.rs

@@ -908,7 +908,8 @@ fn check_error_patterns(props: &TestProps,
     }
     if done { return; }
 
-    let missing_patterns = &props.error_patterns[next_err_idx..];
+    let missing_patterns =
+        props.error_patterns.index(&(next_err_idx..));
     if missing_patterns.len() == 1u {
         fatal_proc_rec(format!("error pattern '{}' not found!",
                               missing_patterns[0]).as_slice(),

branches/beta/src/doc/footer.inc

@@ -1,5 +1,5 @@
 <footer><p>
-Copyright &copy; 2011-2015 The Rust Project Developers. Licensed under the
+Copyright &copy; 2011-2014 The Rust Project Developers. Licensed under the
 <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>
 or the <a href="http://opensource.org/licenses/MIT">MIT license</a>, at your option.
 </p><p>

branches/beta/src/doc/guide-error-handling.md

@@ -147,10 +147,10 @@ for all but the most trivial of situations.
 Here's an example of using `Result`:
 
 ```rust
-#[derive(Show)]
+#[deriving(Show)]
 enum Version { Version1, Version2 }
 
-#[derive(Show)]
+#[deriving(Show)]
 enum ParseError { InvalidHeaderLength, InvalidVersion }
 
 fn parse_version(header: &[u8]) -> Result<Version, ParseError> {

branches/beta/src/doc/guide-ffi.md

@@ -262,7 +262,6 @@ referenced Rust object.
 Rust code:
 
 ~~~~no_run
-# use std::boxed::Box;
 
 #[repr(C)]
 struct RustObject {
@@ -287,7 +286,7 @@ extern {
 
 fn main() {
     // Create the object that will be referenced in the callback
-    let mut rust_object = Box::new(RustObject { a: 5 });
+    let mut rust_object = box RustObject { a: 5 };
 
     unsafe {
         register_callback(&mut *rust_object, callback);

branches/beta/src/doc/guide-ownership.md

@@ -81,29 +81,27 @@ therefore deallocates the memory for you. Here's the equivalent example in
 Rust:
 
 ```rust
-# use std::boxed::Box;
 {
-    let x = Box::new(5i);
+    let x = box 5i;
 }
 ```
 
-The `Box::new` function creates a `Box<T>` (specifically `Box<int>` in this
-case) by allocating a small segment of memory on the heap with enough space to
-fit an `int`. But where in the code is the box deallocated? We said before that
-we must have a deallocation for each allocation. Rust handles this for you. It
+The `box` keyword creates a `Box<T>` (specifically `Box<int>` in this case) by
+allocating a small segment of memory on the heap with enough space to fit an
+`int`. But where in the code is the box deallocated? We said before that we
+must have a deallocation for each allocation. Rust handles this for you. It
 knows that our handle, `x`, is the owning reference to our box. Rust knows that
 `x` will go out of scope at the end of the block, and so it inserts a call to
 deallocate the memory at the end of the scope. Because the compiler does this
-for us, it's impossible to forget. We always have exactly one deallocation
-  paired with each of our allocations.
+for us, it's impossible to forget. We always have exactly one deallocation paired
+with each of our allocations.
 
 This is pretty straightforward, but what happens when we want to pass our box
 to a function? Let's look at some code:
 
 ```rust
-# use std::boxed::Box;
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     add_one(x);
 }
@@ -117,9 +115,8 @@ This code works, but it's not ideal. For example, let's add one more line of
 code, where we print out the value of `x`:
 
 ```{rust,ignore}
-# use std::boxed::Box;
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     add_one(x);
 
@@ -151,9 +148,8 @@ To fix this, we can have `add_one` give ownership back when it's done with the
 box:
 
 ```rust
-# use std::boxed::Box;
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     let y = add_one(x);
 
@@ -462,7 +458,7 @@ lifetime, and so if you elide a lifetime (like `&T` instead of `&'a T`), Rust
 will do three things to determine what those lifetimes should be.
 
 When talking about lifetime elision, we use the term 'input lifetime' and
-'output lifetime'. An 'input lifetime' is a lifetime associated with a parameter
+'output lifetime'. An 'input liftime' is a lifetime associated with a parameter
 of a function, and an 'output lifetime' is a lifetime associated with the return
 value of a function. For example, this function has an input lifetime:
 

branches/beta/src/doc/guide-pointers.md

@@ -455,13 +455,12 @@ fn rc_succ(x: Rc<int>) -> int { *x + 1 }
 Note that the caller of your function will have to modify their calls slightly:
 
 ```{rust}
-# use std::boxed::Box;
 use std::rc::Rc;
 
 fn succ(x: &int) -> int { *x + 1 }
 
 let ref_x = &5i;
-let box_x = Box::new(5i);
+let box_x = box 5i;
 let rc_x  = Rc::new(5i);
 
 succ(ref_x);
@@ -478,17 +477,24 @@ those contents.
 heap allocation in Rust. Creating a box looks like this:
 
 ```{rust}
-# use std::boxed::Box;
-let x = Box::new(5i);
+let x = box(std::boxed::HEAP) 5i;
 ```
 
-Boxes are heap allocated and they are deallocated automatically by Rust when
-they go out of scope:
+`box` is a keyword that does 'placement new,' which we'll talk about in a bit.
+`box` will be useful for creating a number of heap-allocated types, but is not
+quite finished yet. In the meantime, `box`'s type defaults to
+`std::boxed::HEAP`, and so you can leave it off:
+
+```{rust}
+let x = box 5i;
+```
+
+As you might assume from the `HEAP`, boxes are heap allocated. They are
+deallocated automatically by Rust when they go out of scope:
 
 ```{rust}
-# use std::boxed::Box;
 {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     // stuff happens
 
@@ -507,9 +513,8 @@ You don't need to fully grok the theory of affine types or regions to grok
 boxes, though. As a rough approximation, you can treat this Rust code:
 
 ```{rust}
-# use std::boxed::Box;
 {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     // stuff happens
 }
@@ -548,13 +553,12 @@ for more detail on how lifetimes work.
 Using boxes and references together is very common. For example:
 
 ```{rust}
-# use std::boxed::Box;
 fn add_one(x: &int) -> int {
     *x + 1
 }
 
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     println!("{}", add_one(&*x));
 }
@@ -566,13 +570,12 @@ function, and since it's only reading the value, allows it.
 We can borrow `x` multiple times, as long as it's not simultaneous:
 
 ```{rust}
-# use std::boxed::Box;
 fn add_one(x: &int) -> int {
     *x + 1
 }
 
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     println!("{}", add_one(&*x));
     println!("{}", add_one(&*x));
@@ -583,13 +586,12 @@ fn main() {
 Or as long as it's not a mutable borrow. This will error:
 
 ```{rust,ignore}
-# use std::boxed::Box;
 fn add_one(x: &mut int) -> int {
     *x + 1
 }
 
 fn main() {
-    let x = Box::new(5i);
+    let x = box 5i;
 
     println!("{}", add_one(&*x)); // error: cannot borrow immutable dereference
                                   // of `&`-pointer as mutable
@@ -610,23 +612,22 @@ Sometimes, you need a recursive data structure. The simplest is known as a
 
 
 ```{rust}
-# use std::boxed::Box;
-#[derive(Show)]
+#[deriving(Show)]
 enum List<T> {
     Cons(T, Box<List<T>>),
     Nil,
 }
 
 fn main() {
-    let list: List<int> = List::Cons(1, Box::new(List::Cons(2, Box::new(List::Cons(3, Box::new(List::Nil))))));
+    let list: List<int> = List::Cons(1, box List::Cons(2, box List::Cons(3, box List::Nil)));
     println!("{:?}", list);
 }
 ```
 
 This prints:
 
 ```text
-Cons(1, Box(Cons(2, Box(Cons(3, Box(Nil))))))
+Cons(1, box Cons(2, box Cons(3, box Nil)))
 ```
 
 The reference to another `List` inside of the `Cons` enum variant must be a box,
@@ -666,7 +667,6 @@ In many languages with pointers, you'd return a pointer from a function
 so as to avoid copying a large data structure. For example:
 
 ```{rust}
-# use std::boxed::Box;
 struct BigStruct {
     one: int,
     two: int,
@@ -675,15 +675,15 @@ struct BigStruct {
 }
 
 fn foo(x: Box<BigStruct>) -> Box<BigStruct> {
-    return Box::new(*x);
+    return box *x;
 }
 
 fn main() {
-    let x = Box::new(BigStruct {
+    let x = box BigStruct {
         one: 1,
         two: 2,
         one_hundred: 100,
-    });
+    };
 
     let y = foo(x);
 }
@@ -695,7 +695,6 @@ than the hundred `int`s that make up the `BigStruct`.
 This is an antipattern in Rust. Instead, write this:
 
 ```{rust}
-# use std::boxed::Box;
 struct BigStruct {
     one: int,
     two: int,
@@ -708,13 +707,13 @@ fn foo(x: Box<BigStruct>) -> BigStruct {
 }
 
 fn main() {
-    let x = Box::new(BigStruct {
+    let x = box BigStruct {
         one: 1,
         two: 2,
         one_hundred: 100,
-    });
+    };
 
-    let y = Box::new(foo(x));
+    let y = box foo(x);
 }
 ```