---

yaml
---
r: 233147
b: refs/heads/beta
c: b77d2f5
h: refs/heads/master
i:
  233145: 13ec47f
  233143: 9d6ca5e
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: 607c70e50f6ed1827dadd548e367f02d34213f12
+refs/heads/beta: b77d2f5ac7684390c72c99511cb446db0f4ce20a
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
 refs/heads/tmp: 370fe2786109360f7c35b8ba552b83b773dd71d6
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f

branches/beta/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/beta/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/beta/src/doc/trpl/advanced-linking.md

@@ -38,12 +38,12 @@ Static linking refers to the process of creating output that contain all
 required libraries and so don't need libraries installed on every system where
 you want to use your compiled project. Pure-Rust dependencies are statically
 linked by default so you can use created binaries and libraries without
-installing the Rust everywhere. By contrast, native libraries
-(e.g. `libc` and `libm`) usually dynamically linked, but it is possible to
+installing Rust everywhere. By contrast, native libraries
+(e.g. `libc` and `libm`) are usually dynamically linked, but it is possible to
 change this and statically link them as well.
 
-Linking is a very platform dependent topic — on some platforms, static linking
-may not be possible at all! This section assumes some basic familiarity with
+Linking is a very platform-dependent topic, and static linking may not even be
+possible on some platforms! This section assumes some basic familiarity with
 linking on your platform of choice.
 
 ## Linux
@@ -71,8 +71,7 @@ Dynamic linking on Linux can be undesirable if you wish to use new library
 features on old systems or target systems which do not have the required
 dependencies for your program to run.
 
-Static linking is supported via an alternative `libc`, `musl` - this must be
-enabled at Rust compile-time with some prerequisites available. You can compile
+Static linking is supported via an alternative `libc`, `musl`. You can compile
 your own version of Rust with `musl` enabled and install it into a custom
 directory with the instructions below:
 
@@ -123,7 +122,7 @@ $ du -h musldist/bin/rustc
 ```
 
 You now have a build of a `musl`-enabled Rust! Because we've installed it to a
-custom prefix we need to make sure our system can the binaries and appropriate
+custom prefix we need to make sure our system can find the binaries and appropriate
 libraries when we try and run it:
 
 ```text

branches/beta/src/doc/trpl/references-and-borrowing.md

@@ -125,6 +125,10 @@ This will print `6`. We make `y` a mutable reference to `x`, then add one to
 the thing `y` points at. You’ll notice that `x` had to be marked `mut` as well,
 if it wasn’t, we couldn’t take a mutable borrow to an immutable value.
 
+You'll also notice we added an asterisk (`*`) in front of `y`, making it `*y`,
+this is because `y` is an `&mut` reference. You'll also need to use them for
+accessing the contents of a reference as well.
+
 Otherwise, `&mut` references are just like references. There _is_ a large
 difference between the two, and how they interact, though. You can tell
 something is fishy in the above example, because we need that extra scope, with

branches/beta/src/librustc/metadata/creader.rs

@@ -261,6 +261,7 @@ impl<'a> CrateReader<'a> {
         let loader::Library { dylib, rlib, metadata } = lib;
 
         let cnum_map = self.resolve_crate_deps(root, metadata.as_slice(), span);
+        let staged_api = self.is_staged_api(metadata.as_slice());
 
         let cmeta = Rc::new( cstore::crate_metadata {
             name: name.to_string(),
@@ -270,6 +271,7 @@ impl<'a> CrateReader<'a> {
             cnum: cnum,
             codemap_import_info: RefCell::new(vec![]),
             span: span,
+            staged_api: staged_api
         });
 
         let source = cstore::CrateSource {
@@ -283,6 +285,17 @@ impl<'a> CrateReader<'a> {
         (cnum, cmeta, source)
     }
 
+    fn is_staged_api(&self, data: &[u8]) -> bool {
+        let attrs = decoder::get_crate_attributes(data);
+        for attr in &attrs {
+            if &attr.name()[..] == "staged_api" {
+                match attr.node.value.node { ast::MetaWord(_) => return true, _ => (/*pass*/) }
+            }
+        }
+
+        return false;
+    }
+
     fn resolve_crate(&mut self,
                      root: &Option<CratePaths>,
                      ident: &str,

branches/beta/src/librustc/metadata/csearch.rs

@@ -22,7 +22,6 @@ use rbml::reader;
 use std::rc::Rc;
 use syntax::ast;
 use syntax::attr;
-use syntax::attr::AttrMetaMethods;
 use syntax::diagnostic::expect;
 
 use std::collections::hash_map::HashMap;
@@ -386,15 +385,7 @@ pub fn get_stability(cstore: &cstore::CStore,
 }
 
 pub fn is_staged_api(cstore: &cstore::CStore, krate: ast::CrateNum) -> bool {
-    let cdata = cstore.get_crate_data(krate);
-    let attrs = decoder::get_crate_attributes(cdata.data());
-    for attr in &attrs {
-        if &attr.name()[..] == "staged_api" {
-            match attr.node.value.node { ast::MetaWord(_) => return true, _ => (/*pass*/) }
-        }
-    }
-
-    return false;
+    cstore.get_crate_data(krate).staged_api
 }
 
 pub fn get_repr_attrs(cstore: &cstore::CStore, def: ast::DefId)

branches/beta/src/librustc/metadata/cstore.rs

@@ -63,6 +63,7 @@ pub struct crate_metadata {
     pub cnum: ast::CrateNum,
     pub codemap_import_info: RefCell<Vec<ImportedFileMap>>,
     pub span: codemap::Span,
+    pub staged_api: bool
 }
 
 #[derive(Copy, Debug, PartialEq, Clone)]

branches/beta/src/librustc_trans/trans/base.rs

@@ -1299,12 +1299,11 @@ pub fn init_function<'a, 'tcx>(fcx: &'a FunctionContext<'a, 'tcx>,
                 let init_val = C_u8(fcx.ccx, adt::DTOR_NEEDED_HINT);
                 let llname = &format!("dropflag_hint_{}", id);
                 debug!("adding hint {}", llname);
-                let ptr = alloc_ty(entry_bcx, tcx.types.u8, llname);
+                let ty = tcx.types.u8;
+                let ptr = alloc_ty(entry_bcx, ty, llname);
                 Store(entry_bcx, init_val, ptr);
-                let ty = tcx.mk_ptr(ty::TypeAndMut { ty: tcx.types.u8, mutbl: ast::MutMutable });
                 let flag = datum::Lvalue::new_dropflag_hint("base::init_function");
-                let datum = datum::Datum::new(ptr, ty, flag);
-                datum
+                datum::Datum::new(ptr, ty, flag)
             };
 
             let (var, datum) = match info {

branches/beta/src/librustc_typeck/astconv.rs

@@ -1662,6 +1662,9 @@ pub fn ast_ty_to_ty<'tcx>(this: &AstConv<'tcx>,
             // handled specially and will not descend into this routine.
             this.ty_infer(None, None, None, ast_ty.span)
         }
+        ast::TyMac(_) => {
+            tcx.sess.span_bug(ast_ty.span, "unexpanded type macro found conversion")
+        }
     };
 
     tcx.ast_ty_to_ty_cache.borrow_mut().insert(ast_ty.id, typ);

branches/beta/src/librustdoc/clean/mod.rs

@@ -1611,6 +1611,9 @@ impl Clean<Type> for ast::Ty {
             TyTypeof(..) => {
                 panic!("Unimplemented type {:?}", self.node)
             },
+            TyMac(ref m) => {
+                cx.tcx().sess.span_bug(m.span, "unexpanded type macro found during cleaning")
+            }
         }
     }
 }

branches/beta/src/libsyntax/ast.rs

@@ -1471,6 +1471,8 @@ pub enum Ty_ {
     /// TyInfer means the type should be inferred instead of it having been
     /// specified. This can appear anywhere in a type.
     TyInfer,
+    // A macro in the type position.
+    TyMac(Mac)
 }
 
 #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)]

branches/beta/src/libsyntax/ext/base.rs

@@ -290,6 +290,10 @@ pub trait MacResult {
     fn make_stmts(self: Box<Self>) -> Option<SmallVector<P<ast::Stmt>>> {
         make_stmts_default!(self)
     }
+
+    fn make_ty(self: Box<Self>) -> Option<P<ast::Ty>> {
+        None
+    }
 }
 
 macro_rules! make_MacEager {
@@ -322,6 +326,7 @@ make_MacEager! {
     items: SmallVector<P<ast::Item>>,
     impl_items: SmallVector<P<ast::ImplItem>>,
     stmts: SmallVector<P<ast::Stmt>>,
+    ty: P<ast::Ty>,
 }
 
 impl MacResult for MacEager {
@@ -359,6 +364,10 @@ impl MacResult for MacEager {
         }
         None
     }
+
+    fn make_ty(self: Box<Self>) -> Option<P<ast::Ty>> {
+        self.ty
+    }
 }
 
 /// Fill-in macro expansion result, to allow compilation to continue
@@ -405,15 +414,24 @@ impl DummyResult {
         }
     }
 
+    pub fn raw_ty(sp: Span) -> P<ast::Ty> {
+        P(ast::Ty {
+            id: ast::DUMMY_NODE_ID,
+            node: ast::TyInfer,
+            span: sp
+        })
+    }
 }
 
 impl MacResult for DummyResult {
     fn make_expr(self: Box<DummyResult>) -> Option<P<ast::Expr>> {
         Some(DummyResult::raw_expr(self.span))
     }
+
     fn make_pat(self: Box<DummyResult>) -> Option<P<ast::Pat>> {
         Some(P(DummyResult::raw_pat(self.span)))
     }
+
     fn make_items(self: Box<DummyResult>) -> Option<SmallVector<P<ast::Item>>> {
         // this code needs a comment... why not always just return the Some() ?
         if self.expr_only {
@@ -422,13 +440,15 @@ impl MacResult for DummyResult {
             Some(SmallVector::zero())
         }
     }
+
     fn make_impl_items(self: Box<DummyResult>) -> Option<SmallVector<P<ast::ImplItem>>> {
         if self.expr_only {
             None
         } else {
             Some(SmallVector::zero())
         }
     }
+
     fn make_stmts(self: Box<DummyResult>) -> Option<SmallVector<P<ast::Stmt>>> {
         Some(SmallVector::one(P(
             codemap::respan(self.span,