auto merge of #20733 : alexcrichton/rust/rollup, r=alexcrichton

configure

@@ -599,6 +599,18 @@ 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

mk/main.mk

@@ -25,11 +25,13 @@ 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
@@ -121,11 +123,9 @@ 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,11 +319,20 @@ 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

src/compiletest/compiletest.rs

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

src/compiletest/runtest.rs

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

src/doc/footer.inc

@@ -1,5 +1,5 @@
 <footer><p>
-Copyright &copy; 2011-2014 The Rust Project Developers. Licensed under the
+Copyright &copy; 2011-2015 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>

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
-#[deriving(Show)]
+#[derive(Show)]
 enum Version { Version1, Version2 }
 
-#[deriving(Show)]
+#[derive(Show)]
 enum ParseError { InvalidHeaderLength, InvalidVersion }
 
 fn parse_version(header: &[u8]) -> Result<Version, ParseError> {

src/doc/guide-ffi.md

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

src/doc/guide-ownership.md

@@ -81,27 +81,29 @@ therefore deallocates the memory for you. Here's the equivalent example in
 Rust:
 
 ```rust
+# use std::boxed::Box;
 {
-    let x = box 5i;
+    let x = Box::new(5i);
 }
 ```
 
-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
+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
 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 5i;
+    let x = Box::new(5i);
 
     add_one(x);
 }
@@ -115,8 +117,9 @@ 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 5i;
+    let x = Box::new(5i);
 
     add_one(x);
 
@@ -148,8 +151,9 @@ 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 5i;
+    let x = Box::new(5i);
 
     let y = add_one(x);
 
@@ -458,7 +462,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 liftime' is a lifetime associated with a parameter
+'output lifetime'. An 'input lifetime' 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:
 

src/doc/guide-pointers.md

@@ -455,12 +455,13 @@ 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 5i;
+let box_x = Box::new(5i);
 let rc_x  = Rc::new(5i);
 
 succ(ref_x);
@@ -477,24 +478,17 @@ those contents.
 heap allocation in Rust. Creating a box looks like this:
 
 ```{rust}
-let x = box(std::boxed::HEAP) 5i;
+# use std::boxed::Box;
+let x = Box::new(5i);
 ```
 
-`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:
+Boxes are heap allocated and they are deallocated automatically by Rust when
+they go out of scope:
 
 ```{rust}
+# use std::boxed::Box;
 {
-    let x = box 5i;
+    let x = Box::new(5i);
 
     // stuff happens
 
@@ -513,8 +507,9 @@ 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 5i;
+    let x = Box::new(5i);
 
     // stuff happens
 }
@@ -553,12 +548,13 @@ 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 5i;
+    let x = Box::new(5i);
 
     println!("{}", add_one(&*x));
 }
@@ -570,12 +566,13 @@ 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 5i;
+    let x = Box::new(5i);
 
     println!("{}", add_one(&*x));
     println!("{}", add_one(&*x));
@@ -586,12 +583,13 @@ 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 5i;
+    let x = Box::new(5i);
 
     println!("{}", add_one(&*x)); // error: cannot borrow immutable dereference
                                   // of `&`-pointer as mutable
@@ -612,22 +610,23 @@ Sometimes, you need a recursive data structure. The simplest is known as a
 
 
 ```{rust}
-#[deriving(Show)]
+# use std::boxed::Box;
+#[derive(Show)]
 enum List<T> {
     Cons(T, Box<List<T>>),
     Nil,
 }
 
 fn main() {
-    let list: List<int> = List::Cons(1, box List::Cons(2, box List::Cons(3, box List::Nil)));
+    let list: List<int> = List::Cons(1, Box::new(List::Cons(2, Box::new(List::Cons(3, Box::new(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,
@@ -667,6 +666,7 @@ 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 *x;
+    return Box::new(*x);
 }
 
 fn main() {
-    let x = box BigStruct {
+    let x = Box::new(BigStruct {
         one: 1,
         two: 2,
         one_hundred: 100,
-    };
+    });
 
     let y = foo(x);
 }
@@ -695,6 +695,7 @@ 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,
@@ -707,13 +708,13 @@ fn foo(x: Box<BigStruct>) -> BigStruct {
 }
 
 fn main() {
-    let x = box BigStruct {
+    let x = Box::new(BigStruct {
         one: 1,
         two: 2,
         one_hundred: 100,
-    };
+    });
 
-    let y = box foo(x);
+    let y = Box::new(foo(x));
 }
 ```
 

src/doc/guide-unsafe.md

@@ -197,6 +197,7 @@ extern crate libc;
 use libc::{c_void, size_t, malloc, free};
 use std::mem;
 use std::ptr;
+# use std::boxed::Box;
 
 // Define a wrapper around the handle returned by the foreign code.
 // Unique<T> has the same semantics as Box<T>
@@ -265,7 +266,7 @@ impl<T: Send> Drop for Unique<T> {
 // A comparison between the built-in `Box` and this reimplementation
 fn main() {
     {
-        let mut x = box 5i;
+        let mut x = Box::new(5i);
         *x = 10;
     } // `x` is freed here
 
@@ -653,7 +654,7 @@ sugar for dynamic allocations via `malloc` and `free`:
 
 ```
 #![no_std]
-#![feature(lang_items)]
+#![feature(lang_items, box_syntax)]
 
 extern crate libc;