---

yaml
---
r: 227166
b: refs/heads/auto
c: 8c4dc18
h: refs/heads/master
v: v3

Author: steveklabnik

[refs]

@@ -8,7 +8,7 @@ refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 23f43896ce92830173e503eab8b2f7fba8137e37
+refs/heads/auto: 8c4dc18d2a51321070abccd34182381bdc66054d
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336
 refs/tags/0.2: 1754d02027f2924bed83b0160ee340c7f41d5ea1

branches/auto/mk/clean.mk

@@ -101,6 +101,7 @@ define CLEAN_TARGET_STAGE_N
 clean$(1)_T_$(2)_H_$(3): \
 	    $$(foreach crate,$$(CRATES),clean$(1)_T_$(2)_H_$(3)-lib-$$(crate)) \
 	    $$(foreach tool,$$(TOOLS) $$(DEBUGGER_BIN_SCRIPTS_ALL),clean$(1)_T_$(2)_H_$(3)-tool-$$(tool))
+	$$(Q)rm -f $$(TLIB$(1)_T_$(2)_H_$(3))/libmorestack.a
 	$$(Q)rm -f $$(TLIB$(1)_T_$(2)_H_$(3))/libcompiler-rt.a
 	$(Q)rm -f $$(TLIB$(1)_T_$(2)_H_$(3))/librun_pass_stage* # For unix
 	$(Q)rm -f $$(TLIB$(1)_T_$(2)_H_$(3))/run_pass_stage* # For windows

branches/auto/mk/crates.mk

@@ -65,7 +65,7 @@ DEPS_libc := core
 DEPS_rustc_unicode := core
 DEPS_alloc := core libc native:jemalloc
 DEPS_std := core libc rand alloc collections rustc_unicode \
-	native:rust_builtin native:backtrace \
+	native:rust_builtin native:backtrace native:rustrt_native \
 	rustc_bitflags
 DEPS_graphviz := std
 DEPS_syntax := std term serialize log fmt_macros arena libc

branches/auto/mk/main.mk

@@ -163,7 +163,7 @@ endif
 # that the snapshot will be generated with a statically linked rustc so we only
 # have to worry about the distribution of one file (with its native dynamic
 # dependencies)
-RUSTFLAGS_STAGE0 += -C prefer-dynamic -C no-stack-check
+RUSTFLAGS_STAGE0 += -C prefer-dynamic
 RUSTFLAGS_STAGE1 += -C prefer-dynamic
 RUST_LIB_FLAGS_ST2 += -C prefer-dynamic
 RUST_LIB_FLAGS_ST3 += -C prefer-dynamic
@@ -400,11 +400,6 @@ TSREQ$(1)_T_$(2)_H_$(3) = \
 	$$(foreach obj,$$(INSTALLED_OBJECTS_$(2)),\
 		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(obj))
 
-ifeq ($(1),0)
-TSREQ$(1)_T_$(2)_H_$(3) += \
-	$$(TLIB$(1)_T_$(2)_H_$(3))/$$(call CFG_STATIC_LIB_NAME_$(2),morestack)
-endif
-
 # Prerequisites for a working stageN compiler and libraries, for a specific
 # target
 SREQ$(1)_T_$(2)_H_$(3) = \

branches/auto/mk/platform.mk

@@ -113,7 +113,8 @@ CFG_RLIB_GLOB=lib$(1)-*.rlib
 include $(wildcard $(CFG_SRC_DIR)mk/cfg/*.mk)
 
 define ADD_INSTALLED_OBJECTS
-  INSTALLED_OBJECTS_$(1) += $$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
+  INSTALLED_OBJECTS_$(1) += $$(call CFG_STATIC_LIB_NAME_$(1),morestack) \
+                            $$(call CFG_STATIC_LIB_NAME_$(1),compiler-rt)
 endef
 
 $(foreach target,$(CFG_TARGET), \
@@ -242,9 +243,6 @@ $(foreach target,$(CFG_TARGET), \
 # Windows MSVC in the compiler, but the gist of it is that we use `llvm-ar.exe`
 # instead of `lib.exe` for assembling archives, so we need to inject this custom
 # dependency here.
-#
-# FIXME(stage0): remove this and all other relevant support in the makefiles
-#                after a snapshot is made
 define ADD_LLVM_AR_TO_MSVC_DEPS
 ifeq ($$(findstring msvc,$(1)),msvc)
 NATIVE_TOOL_DEPS_core_T_$(1) += llvm-ar.exe
@@ -280,15 +278,10 @@ $(foreach target,$(CFG_TARGET), \
 # Fun times!
 #
 # [1]: https://msdn.microsoft.com/en-us/library/28d6s79h.aspx
-#
-# FIXME(stage0): remove this macro and the usage below (and the commments above)
-# 	         when a new snapshot is available. Also remove the
-# 	         RUSTFLAGS$(1)_.._T_ variable in mk/target.mk along with
-# 	         CUSTOM_DEPS (as they were only added for this)
 define ADD_RUSTC_LLVM_DEF_TO_MSVC
 ifeq ($$(findstring msvc,$(1)),msvc)
-RUSTFLAGS0_rustc_llvm_T_$(1) += -C link-args="-DEF:$(1)/rt/rustc_llvm.def"
-CUSTOM_DEPS0_rustc_llvm_T_$(1) += $(1)/rt/rustc_llvm.def
+RUSTFLAGS_rustc_llvm_T_$(1) += -C link-args="-DEF:$(1)/rt/rustc_llvm.def"
+CUSTOM_DEPS_rustc_llvm_T_$(1) += $(1)/rt/rustc_llvm.def
 
 $(1)/rt/rustc_llvm.def: $$(S)src/etc/mklldef.py $$(S)src/librustc_llvm/lib.rs
 	$$(CFG_PYTHON) $$^ $$@ rustc_llvm-$$(CFG_FILENAME_EXTRA)

branches/auto/mk/rt.mk

@@ -35,8 +35,8 @@
 # that's per-target so you're allowed to conditionally add files based on the
 # target.
 ################################################################################
-NATIVE_LIBS := rust_builtin hoedown miniz \
-		rust_test_helpers morestack
+NATIVE_LIBS := rust_builtin hoedown morestack miniz \
+		rustrt_native rust_test_helpers
 
 # $(1) is the target triple
 define NATIVE_LIBRARIES
@@ -53,8 +53,10 @@ NATIVE_DEPS_hoedown_$(1) := hoedown/src/autolink.c \
 NATIVE_DEPS_miniz_$(1) = miniz.c
 NATIVE_DEPS_rust_builtin_$(1) := rust_builtin.c \
 			rust_android_dummy.c
+NATIVE_DEPS_rustrt_native_$(1) := arch/$$(HOST_$(1))/record_sp.S
 NATIVE_DEPS_rust_test_helpers_$(1) := rust_test_helpers.c
-NATIVE_DEPS_morestack_$(1) := empty.c
+NATIVE_DEPS_morestack_$(1) := arch/$$(HOST_$(1))/morestack.S
+
 
 ################################################################################
 # You shouldn't find it that necessary to edit anything below this line.

branches/auto/mk/target.mk

@@ -40,7 +40,7 @@ CRATE_FULLDEPS_$(1)_T_$(2)_H_$(3)_$(4) := \
 		  $$(RT_OUTPUT_DIR_$(2))/$$(dep)) \
 		$$(foreach dep,$$(NATIVE_TOOL_DEPS_$(4)_T_$(2)), \
 		  $$(TBIN$(1)_T_$(3)_H_$(3))/$$(dep)) \
-		$$(CUSTOM_DEPS$(1)_$(4)_T_$(2))
+		$$(CUSTOM_DEPS_$(4)_T_$(2))
 endef
 
 $(foreach host,$(CFG_HOST), \
@@ -56,7 +56,8 @@ $(foreach host,$(CFG_HOST), \
 #   1. The immediate dependencies are the rust source files
 #   2. Each rust crate dependency is listed (based on their stamp files),
 #      as well as all native dependencies (listed in RT_OUTPUT_DIR)
-#   3. The stage (n-1) compiler is required through the TSREQ dependency
+#   3. The stage (n-1) compiler is required through the TSREQ dependency, along
+#      with the morestack library
 #   4. When actually executing the rule, the first thing we do is to clean out
 #      old libs and rlibs via the REMOVE_ALL_OLD_GLOB_MATCHES macro
 #   5. Finally, we get around to building the actual crate. It's just one
@@ -92,7 +93,7 @@ $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \
 		$$(LLVM_LIBDIR_RUSTFLAGS_$(2)) \
 		$$(LLVM_STDCPP_RUSTFLAGS_$(2)) \
 		$$(RUSTFLAGS_$(4)) \
-		$$(RUSTFLAGS$(1)_$(4)_T_$(2)) \
+		$$(RUSTFLAGS_$(4)_T_$(2)) \
 		--out-dir $$(@D) \
 		-C extra-filename=-$$(CFG_FILENAME_EXTRA) \
 		$$<
@@ -205,9 +206,6 @@ $(foreach host,$(CFG_HOST), \
 # $(3) - triple snapshot is built for
 # $(4) - crate
 # $(5) - tool
-#
-# FIXME(stage0): remove this and all other relevant support in the makefiles
-#                after a snapshot is made
 define MOVE_TOOLS_TO_SNAPSHOT_HOST_DIR
 ifneq (,$(3))
 $$(TLIB$(1)_T_$(2)_H_$(2))/stamp.$(4): $$(HLIB$(1)_H_$(2))/rustlib/$(3)/bin/$(5)
@@ -232,9 +230,6 @@ $(foreach target,$(CFG_TARGET), \
 #   path instead of MinGW's /usr/bin/link.exe (entirely unrelated)
 #
 # The values for these variables are detected by the configure script.
-#
-# FIXME(stage0): remove this and all other relevant support in the makefiles
-#                after a snapshot is made
 define SETUP_LIB_MSVC_ENV_VARS
 ifeq ($$(findstring msvc,$(2)),msvc)
 $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4): \

branches/auto/src/compiletest/procsrv.rs

@@ -26,7 +26,8 @@ fn add_target_env(cmd: &mut Command, lib_path: &str, aux_path: Option<&str>) {
     // Add the new dylib search path var
     let var = DynamicLibrary::envvar();
     let newpath = DynamicLibrary::create_path(&path);
-    cmd.env(var, newpath);
+    let newpath = newpath.to_str().unwrap().to_string();
+    cmd.env(var, &newpath);
 }
 
 pub struct Result {pub status: ExitStatus, pub out: String, pub err: String}

branches/auto/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)
-may return `nullptr` when a zero-sized allocation is requested, which is
-indistinguishable from out of memory.
+generally consider passing in `0` for the size of an allocation as Undefined
+Behaviour.
 
 
 

branches/auto/src/doc/nomicon/lifetimes.md

@@ -52,7 +52,8 @@ likely desugar to the following:
 }
 ```
 
-Wow. That's... awful. Let's all take a moment to thank Rust for making this easier.
+Wow. That's... awful. Let's all take a moment to thank Rust for being a
+diabetes-inducing torrent of syrupy-goodness.
 
 Actually passing references to outer scopes will cause Rust to infer
 a larger lifetime:

branches/auto/src/doc/nomicon/repr-rust.md

@@ -36,9 +36,9 @@ struct A {
 }
 ```
 
-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:
+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:
 
 ```rust
 struct A {
@@ -50,10 +50,10 @@ struct A {
 }
 ```
 
-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:
+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:
 
 ```rust
 struct A {
@@ -62,17 +62,18 @@ struct A {
 }
 
 struct B {
-    a: i32,
+    x: 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* 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.
+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).
 
-With A and B as written, this point would seem to be pedantic, but several other
+With A and B as written, this is basically nonsensical, but several other
 features of Rust make it desirable for the language to play with data layout in
 complex ways.
 
@@ -132,21 +133,18 @@ 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": 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>()`.
+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>()`
 
-There are many types in Rust that are, or contain, non-nullable pointers such as
+There are many types in Rust that are, or contain, "not null" 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 could
+definition known to have a limited range of valid values. In principle enums can
 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/auto/src/doc/reference.md

@@ -1501,29 +1501,7 @@ have an implementation for `Shape`. Multiple supertraits are separated by `+`,
 `trait Circle : Shape + PartialEq { }`. In an implementation of `Circle` for a
 given type `T`, methods can refer to `Shape` methods, since the typechecker
 checks that any type with an implementation of `Circle` also has an
-implementation of `Shape`:
-
-```rust
-struct Foo;
-
-trait Shape { fn area(&self) -> f64; }
-trait Circle : Shape { fn radius(&self) -> f64; }
-# impl Shape for Foo {
-#     fn area(&self) -> f64 {
-#         0.0
-#     }
-# }
-impl Circle for Foo {
-    fn radius(&self) -> f64 {
-        println!("calling area: {}", self.area());
-
-        0.0
-    }
-}
-
-let c = Foo;
-c.radius();
-```
+implementation of `Shape`.
 
 In type-parameterized functions, methods of the supertrait may be called on
 values of subtrait-bound type parameters. Referring to the previous example of
@@ -1924,16 +1902,10 @@ On an `extern` block, the following attributes are interpreted:
   name and type. This is feature gated and the exact behavior is
   implementation-defined (due to variety of linker invocation syntax).
 - `link` - indicate that a native library should be linked to for the
-  declarations in this block to be linked correctly. `link` supports an optional
-  `kind` key with three possible values: `dylib`, `static`, and `framework`. See
-  [external blocks](#external-blocks) for more about external blocks. Two
+  declarations in this block to be linked correctly. `link` supports an optional `kind`
+  key with three possible values: `dylib`, `static`, and `framework`. See [external blocks](#external-blocks) for more about external blocks. Two
   examples: `#[link(name = "readline")]` and
   `#[link(name = "CoreFoundation", kind = "framework")]`.
-- `linked_from` - indicates what native library this block of FFI items is
-  coming from. This attribute is of the form `#[linked_from = "foo"]` where
-  `foo` is the name of a library in either `#[link]` or a `-l` flag. This
-  attribute is currently required to export symbols from a Rust dynamic library
-  on Windows, and it is feature gated behind the `linked_from` feature.
 
 On declarations inside an `extern` block, the following attributes are
 interpreted:

branches/auto/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 Rust everywhere. By contrast, native libraries
-(e.g. `libc` and `libm`) are usually dynamically linked, but it is possible to
+installing the Rust everywhere. By contrast, native libraries
+(e.g. `libc` and `libm`) usually dynamically linked, but it is possible to
 change this and statically link them as well.
 
-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 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 on your platform of choice.
 
 ## Linux
@@ -71,7 +71,8 @@ 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`. You can compile
+Static linking is supported via an alternative `libc`, `musl` - this must be
+enabled at Rust compile-time with some prerequisites available. You can compile
 your own version of Rust with `musl` enabled and install it into a custom
 directory with the instructions below:
 
@@ -122,7 +123,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 find the binaries and appropriate
+custom prefix we need to make sure our system can the binaries and appropriate
 libraries when we try and run it:
 
 ```text

branches/auto/src/doc/trpl/closures.md

@@ -316,35 +316,6 @@ assert_eq!(3, answer);
 Now we take a trait object, a `&Fn`. And we have to make a reference
 to our closure when we pass it to `call_with_one`, so we use `&||`.
 
-# Function pointers and closures
-
-A function pointer is kind of like a closure that has no environment. As such,
-you can pass a function pointer to any function expecting a closure argument,
-and it will work:
-
-```rust
-fn call_with_one(some_closure: &Fn(i32) -> i32) -> i32 {
-    some_closure(1)
-}
-
-fn add_one(i: i32) -> i32 {
-    i + 1
-}
-
-let f = add_one;
-
-let answer = call_with_one(&f);
-
-assert_eq!(2, answer);
-```
-
-In this example, we don’t strictly need the intermediate variable `f`,
-the name of the function works just fine too:
-
-```ignore
-let answer = call_with_one(&add_one);
-```
-
 # Returning closures
 
 It’s very common for functional-style code to return closures in various