---

yaml
---
r: 234199
b: refs/heads/beta
c: 6873b9f
h: refs/heads/master
i:
  234197: b834b2a
  234195: 725a97f
  234191: 5353b85
v: v3

Author: bors

[refs]

@@ -23,7 +23,7 @@ refs/tags/0.9: 36870b185fc5f5486636d4515f0e22677493f225
 refs/tags/0.10: ac33f2b15782272ae348dbd7b14b8257b2148b5a
 refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
 refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
-refs/heads/beta: 15d5c0878d93c553558bf23245c6be6f7ab65fab
+refs/heads/beta: 6873b9fee4af732fe81d54fdcedbd31201e3edf0
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
 refs/heads/tmp: 370fe2786109360f7c35b8ba552b83b773dd71d6
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f

branches/beta/COMPILER_TESTS.md

@@ -0,0 +1,43 @@
+# Compiler Test Documentation
+
+In the Rust project, we use a special set of comands imbedded in
+comments to test the Rust compiler. There are two groups of commands:
+
+1. Header commands
+2. Error info commands
+
+Both types of commands are inside comments, but header commands should
+be in a comment before any code.
+
+## Summary of Error Info Commands
+
+Error commands specify something about certain lines of the
+program. They tell the test what kind of error and what message you
+are expecting.
+
+* `~`: Associates the following error level and message with the
+  current line
+* `~|`: Associates the following error level and message with the same
+  line as the previous comment
+* `~^`: Associates the following error level and message with the
+  previous line. Each caret (`^`) that you add adds a line to this, so
+  `~^^^^^^^` is seven lines up.
+
+The error levels that you can have are:
+1. `ERROR`
+2. `WARNING`
+3. `NOTE`
+4. `HELP` and `SUGGESTION`*
+
+\* **Note**: `SUGGESTION` must follow emediatly after `HELP`.
+
+## Summary of Header Commands
+
+Header commands specify something about the entire test file, as a
+whole, instead of just a few lines inside the test.
+
+* `ignore-X` where `X` is an architecture, OS or stage will ignore the test accordingly
+* `ignore-pretty` will not compile the pretty-printed test (this is done to test the pretty-printer, but might not always work)
+* `ignore-test` always ignores the test
+* `ignore-lldb` and `ignore-gdb` will skip the debuginfo tests
+* `min-{gdb,lldb}-version`

branches/beta/CONTRIBUTING.md

@@ -10,6 +10,7 @@ links to the major sections:
 * [Writing Documentation](#writing-documentation)
 * [Issue Triage](#issue-triage)
 * [Out-of-tree Contributions](#out-of-tree-contributions)
+* [Helpful Links and Information](#helpful-links-and-information)
 
 If you have questions, please make a post on [internals.rust-lang.org][internals] or
 hop on [#rust-internals][pound-rust-internals].
@@ -210,3 +211,28 @@ valuable!
 [users]: https://users.rust-lang.org/
 [so]: http://stackoverflow.com/questions/tagged/rust
 [community-library]: https://github.com/rust-lang/rfcs/labels/A-community-library
+
+## Helpful Links and Information
+
+For people new to Rust, and just starting to contribute, or even for
+more seasoned developers, some useful places to look for information
+are:
+
+* The [Rust Internals forum][rif], a place to ask questions and
+  discuss Rust's internals
+* The [generated documentation for rust's compiler][gdfrustc]
+* The [rust referance][rr], even though it doesn't specifically talk about Rust's internals, its a great reasource nontheless
+* Although out of date, [Tom Lee's great blog article][tlgba] is very helpful
+* [rustaceans.org][ro] is helpful, but mostly dedicated to IRC
+* The [Rust Compiler Testing Docs][rctd]
+* For @bors, [this cheetsheat][cheetsheat] is helpful (Remember to replace `@homu` with `@bors` in the commands that you use.)
+* **Google**!
+* Don't be afraid to ask! The Rust community is friendly and helpful.
+
+[gdfrustc]: http://manishearth.github.io/rust-internals-docs/rustc/
+[rif]: http://internals.rust-lang.org
+[rr]: https://doc.rust-lang.org/book/README.html
+[tlgba]: http://tomlee.co/2014/04/03/a-more-detailed-tour-of-the-rust-compiler/
+[ro]: http://www.rustaceans.org/
+[rctd]: ./COMPILER_TESTS.md
+[cheetsheat]: http://buildbot.rust-lang.org/homu/

branches/beta/configure

@@ -1191,12 +1191,21 @@ do
             #
             # Consequently here we try to detect when that happens and print an
             # error if it does.
-            if $CFG_PYTHON -c 'import sys; print sys.argv[1]' `pwd` | grep '^/'
+            if $CFG_PYTHON -c 'import sys; print sys.argv[1]' `pwd` | grep '^/' > /dev/null
             then
-                err "python is silently translating windows paths to MSYS paths \
-                     and the build will fail if this python is used.\n\n \
-                     Either an official python install must be used or an \
-                     alternative python package in MinGW must be used."
+                err "
+
+python is silently translating windows paths to MSYS paths \
+and the build will fail if this python is used.
+
+Either an official python install must be used or an \
+alternative python package in MinGW must be used.
+
+If you are building under msys2 try installing the mingw-w64-x86_64-python2 \
+package instead of python2:
+
+$ pacman -R python2 && pacman -S mingw-w64-x86_64-python2
+"
             fi
 
             # MSVC requires cmake because that's how we're going to build LLVM
@@ -1207,10 +1216,19 @@ do
             # detect that here and error.
             if ! "$CFG_CMAKE" --help | sed -n '/^Generators/,$p' | grep 'Visual Studio' > /dev/null
             then
-                err "cmake does not support Visual Studio generators.\n\n \
-                     This is likely due to it being an msys/cygwin build of cmake, \
-                     rather than the required windows version, built using MinGW \
-                     or Visual Studio."
+                err "
+
+cmake does not support Visual Studio generators.
+
+This is likely due to it being an msys/cygwin build of cmake, \
+rather than the required windows version, built using MinGW \
+or Visual Studio.
+
+If you are building under msys2 try installing the mingw-w64-x86_64-cmake \
+package instead of cmake:
+
+$ pacman -R cmake && pacman -S mingw-w64-x86_64-cmake
+"
             fi
 
             # Use the REG program to figure out where VS is installed

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

@@ -26,13 +26,16 @@ this is totally fine.
 For instance, a custom implementation of `Box` might write `Drop` like this:
 
 ```rust
-#![feature(heap_api, core_intrinsics, unique)]
+#![feature(alloc, heap_api, core_intrinsics, unique)]
+
+extern crate alloc;
 
-use std::rt::heap;
 use std::ptr::Unique;
 use std::intrinsics::drop_in_place;
 use std::mem;
 
+use alloc::heap;
+
 struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
@@ -45,22 +48,26 @@ impl<T> Drop for Box<T> {
         }
     }
 }
+# fn main() {}
 ```
 
 and this works fine because when Rust goes to drop the `ptr` field it just sees
-a [Unique][] that has no actual `Drop` implementation. Similarly nothing can
+a [Unique] that has no actual `Drop` implementation. Similarly nothing can
 use-after-free the `ptr` because when drop exits, it becomes inacessible.
 
 However this wouldn't work:
 
 ```rust
-#![feature(heap_api, core_intrinsics, unique)]
+#![feature(alloc, heap_api, core_intrinsics, unique)]
+
+extern crate alloc;
 
-use std::rt::heap;
 use std::ptr::Unique;
 use std::intrinsics::drop_in_place;
 use std::mem;
 
+use alloc::heap;
+
 struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
@@ -87,6 +94,7 @@ impl<T> Drop for SuperBox<T> {
         }
     }
 }
+# fn main() {}
 ```
 
 After we deallocate the `box`'s ptr in SuperBox's destructor, Rust will
@@ -129,13 +137,16 @@ The classic safe solution to overriding recursive drop and allowing moving out
 of Self during `drop` is to use an Option:
 
 ```rust
-#![feature(heap_api, core_intrinsics, unique)]
+#![feature(alloc, heap_api, core_intrinsics, unique)]
+
+extern crate alloc;
 
-use std::rt::heap;
 use std::ptr::Unique;
 use std::intrinsics::drop_in_place;
 use std::mem;
 
+use alloc::heap;
+
 struct Box<T>{ ptr: Unique<T> }
 
 impl<T> Drop for Box<T> {
@@ -165,6 +176,7 @@ impl<T> Drop for SuperBox<T> {
         }
     }
 }
+# fn main() {}
 ```
 
 However this has fairly odd semantics: you're saying that a field that *should*

branches/beta/src/doc/nomicon/meet-safe-and-unsafe.md

@@ -60,8 +60,8 @@ Unlike C, Undefined Behaviour is pretty limited in scope in Rust. All the core
 language cares about is preventing the following things:
 
 * Dereferencing null or dangling pointers
-* Reading [uninitialized memory][]
-* Breaking the [pointer aliasing rules][]
+* Reading [uninitialized memory]
+* Breaking the [pointer aliasing rules]
 * Producing invalid primitive values:
     * dangling/null references
     * a `bool` that isn't 0 or 1

branches/beta/src/doc/nomicon/other-reprs.md

@@ -26,7 +26,7 @@ still consumes a byte of space.
 * DSTs, tuples, and tagged unions are not a concept in C and as such are never
 FFI safe.
 
-* **If the type would have any [drop flags][], they will still be added**
+* **If the type would have any [drop flags], they will still be added**
 
 * This is equivalent to one of `repr(u*)` (see the next section) for enums. The
 chosen size is the default enum size for the target platform's C ABI. Note that

branches/beta/src/doc/nomicon/safe-unsafe-meaning.md

@@ -35,7 +35,7 @@ unchecked contracts:
 
 There is also `#[unsafe_no_drop_flag]`, which is a special case that exists for
 historical reasons and is in the process of being phased out. See the section on
-[drop flags][] for details.
+[drop flags] for details.
 
 Some examples of unsafe functions:
 
@@ -44,7 +44,7 @@ Some examples of unsafe functions:
 * `ptr::offset` is an intrinsic that invokes Undefined Behaviour if it is
   not "in bounds" as defined by LLVM.
 * `mem::transmute` reinterprets some value as having the given type,
-  bypassing type safety in arbitrary ways. (see [conversions][] for details)
+  bypassing type safety in arbitrary ways. (see [conversions] for details)
 * All FFI functions are `unsafe` because they can do arbitrary things.
   C being an obvious culprit, but generally any language can do something
   that Rust isn't happy about.

branches/beta/src/doc/nomicon/send-and-sync.md

@@ -10,7 +10,7 @@ captures this through the `Send` and `Sync` traits.
 
 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
+foremost, they're [unsafe traits]. This means that they are unsafe to
 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

branches/beta/src/doc/nomicon/transmutes.md

@@ -21,7 +21,7 @@ same size. The ways to cause Undefined Behaviour with this are mind boggling.
     * No you can't do it
     * No you're not special
 * Transmuting to a reference without an explicitly provided lifetime
-  produces an [unbounded lifetime][]
+  produces an [unbounded lifetime]
 
 `mem::transmute_copy<T, U>` somehow manages to be *even more* wildly unsafe than
 this. It copies `size_of<U>` bytes out of an `&T` and interprets them as a `U`.

branches/beta/src/doc/nomicon/vec-alloc.md

@@ -9,7 +9,7 @@ This is perfectly fine because we already have `cap == 0` as our sentinel for no
 allocation. We don't even need to handle it specially in almost any code because
 we usually need to check if `cap > len` or `len > 0` anyway. The traditional
 Rust value to put here is `0x01`. The standard library actually exposes this
-as `std::rt::heap::EMPTY`. There are quite a few places where we'll
+as `alloc::heap::EMPTY`. There are quite a few places where we'll
 want to use `heap::EMPTY` because there's no real allocation to talk about but
 `null` would make the compiler do bad things.
 
@@ -20,11 +20,12 @@ the `heap` API anyway, so let's just get that dependency over with.
 So:
 
 ```rust,ignore
-#![feature(heap_api)]
+#![feature(alloc, heap_api)]
 
-use std::rt::heap::EMPTY;
 use std::mem;
 
+use alloc::heap::EMPTY;
+
 impl<T> Vec<T> {
     fn new() -> Self {
         assert!(mem::size_of::<T>() != 0, "We're not ready to handle ZSTs");

branches/beta/src/doc/nomicon/vec-final.md

@@ -2,17 +2,16 @@
 
 ```rust
 #![feature(unique)]
-#![feature(heap_api)]
+#![feature(alloc, heap_api)]
+
+extern crate alloc;
 
 use std::ptr::{Unique, self};
-use std::rt::heap;
 use std::mem;
 use std::ops::{Deref, DerefMut};
 use std::marker::PhantomData;
 
-
-
-
+use alloc::heap;
 
 struct RawVec<T> {
     ptr: Unique<T>,

branches/beta/src/doc/reference.md

@@ -2367,9 +2367,6 @@ The currently implemented features of the reference compiler are:
             into a Rust program. This capability, 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.
-
 * `struct_variant` - Structural enum variants (those with named fields). It is
                      currently unknown whether this style of enum variant is as
                      fully supported as the tuple-forms, and it's not certain