---

yaml
---
r: 152359
b: refs/heads/try2
c: ffdb881
h: refs/heads/master
i:
  152357: 184e6d9
  152355: 39dc182
  152351: a72aeca
v: v3

Author: bors

[refs]

@@ -5,7 +5,7 @@ refs/heads/snap-stage3: 78a7676898d9f80ab540c6df5d4c9ce35bb50463
 refs/heads/try: 519addf6277dbafccbb4159db4b710c37eaa2ec5
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
-refs/heads/try2: 4666792ac600f4e4e1c09a37b88f40f6125b57b8
+refs/heads/try2: ffdb881337911e65f25dba2dc6e67aed29ffa4cc
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/mk/crates.mk

@@ -51,7 +51,7 @@
 
 TARGET_CRATES := libc std green rustuv native flate arena glob term semver \
                  uuid serialize sync getopts collections num test time rand \
-                 url log regex graphviz core rlibc alloc debug
+                 url log regex graphviz core rlibc alloc debug rustrt
 HOST_CRATES := syntax rustc rustdoc fourcc hexfloat regex_macros fmt_macros
 CRATES := $(TARGET_CRATES) $(HOST_CRATES)
 TOOLS := compiletest rustdoc rustc
@@ -60,7 +60,9 @@ DEPS_core :=
 DEPS_rlibc :=
 DEPS_alloc := core libc native:jemalloc
 DEPS_debug := std
-DEPS_std := core rand libc alloc collections native:rustrt native:backtrace
+DEPS_rustrt := alloc core libc collections native:rustrt_native
+DEPS_std := core libc rand alloc collections rustrt \
+	native:rust_builtin native:backtrace
 DEPS_graphviz := std
 DEPS_green := std native:context_switch
 DEPS_rustuv := std native:uv native:uv_support

branches/try2/mk/docs.mk

@@ -43,7 +43,9 @@ L10N_LANGS := ja
 
 # The options are passed to the documentation generators.
 RUSTDOC_HTML_OPTS_NO_CSS = --markdown-before-content=doc/version_info.html \
-	--markdown-in-header=doc/favicon.inc --markdown-after-content=doc/footer.inc
+	--markdown-in-header=doc/favicon.inc \
+	--markdown-after-content=doc/footer.inc \
+	--markdown-playground-url='http://play.rust-lang.org/'
 
 RUSTDOC_HTML_OPTS = $(RUSTDOC_HTML_OPTS_NO_CSS) --markdown-css rust.css
 

branches/try2/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 := rustrt hoedown uv_support morestack miniz context_switch \
-		rust_test_helpers
+NATIVE_LIBS := rust_builtin hoedown uv_support morestack miniz context_switch \
+		rustrt_native rust_test_helpers
 
 # $(1) is the target triple
 define NATIVE_LIBRARIES
@@ -52,8 +52,9 @@ NATIVE_DEPS_hoedown_$(1) := hoedown/src/autolink.c \
 			hoedown/src/version.c
 NATIVE_DEPS_uv_support_$(1) := rust_uv.c
 NATIVE_DEPS_miniz_$(1) = miniz.c
-NATIVE_DEPS_rustrt_$(1) := rust_builtin.c \
-			rust_android_dummy.c \
+NATIVE_DEPS_rust_builtin_$(1) := rust_builtin.c \
+			rust_android_dummy.c
+NATIVE_DEPS_rustrt_native_$(1) := \
 			rust_try.ll \
 			arch/$$(HOST_$(1))/record_sp.S
 NATIVE_DEPS_rust_test_helpers_$(1) := rust_test_helpers.c

branches/try2/mk/tests.mk

@@ -818,7 +818,7 @@ endif
 ifeq ($(2),$$(CFG_BUILD))
 $$(call TEST_OK_FILE,$(1),$(2),$(3),doc-crate-$(4)): $$(CRATEDOCTESTDEP_$(1)_$(2)_$(3)_$(4))
 	@$$(call E, run doc-crate-$(4) [$(2)])
-	$$(Q)$$(RUSTDOC_$(1)_T_$(2)_H_$(3)) --test \
+	$$(Q)$$(RUSTDOC_$(1)_T_$(2)_H_$(3)) --test --cfg dox \
 	    	$$(CRATEFILE_$(4)) --test-args "$$(TESTARGS)" && touch $$@
 else
 $$(call TEST_OK_FILE,$(1),$(2),$(3),doc-crate-$(4)):

branches/try2/src/compiletest/runtest.rs

@@ -1545,7 +1545,7 @@ fn disassemble_extract(config: &Config, _props: &TestProps,
 fn count_extracted_lines(p: &Path) -> uint {
     let x = File::open(&p.with_extension("ll")).read_to_end().unwrap();
     let x = str::from_utf8(x.as_slice()).unwrap();
-    x.lines().len()
+    x.lines().count()
 }
 
 

branches/try2/src/doc/footer.inc

@@ -5,3 +5,5 @@ or the <a href="http://opensource.org/licenses/MIT">MIT license</a>, at your opt
 </p><p>
 This file may not be copied, modified, or distributed except according to those terms.
 </p></footer>
+<script type="text/javascript" src="jquery.js"></script>
+<script type="text/javascript" src="playpen.js"></script>

branches/try2/src/doc/guide-macros.md

@@ -11,7 +11,7 @@ which both pattern-match on their input and both return early in one case,
 doing nothing otherwise:
 
 ~~~~
-# enum T { SpecialA(uint), SpecialB(uint) };
+# enum T { SpecialA(uint), SpecialB(uint) }
 # fn f() -> uint {
 # let input_1 = SpecialA(0);
 # let input_2 = SpecialA(0);
@@ -37,7 +37,8 @@ lightweight custom syntax extensions, themselves defined using the
 the pattern in the above code:
 
 ~~~~
-# enum T { SpecialA(uint), SpecialB(uint) };
+# #![feature(macro_rules)]
+# enum T { SpecialA(uint), SpecialB(uint) }
 # fn f() -> uint {
 # let input_1 = SpecialA(0);
 # let input_2 = SpecialA(0);
@@ -55,6 +56,7 @@ early_return!(input_1 SpecialA);
 early_return!(input_2 SpecialB);
 # return 0;
 # }
+# fn main() {}
 ~~~~
 
 Macros are defined in pattern-matching style: in the above example, the text
@@ -155,7 +157,8 @@ separator token (a comma-separated list could be written `$(...),*`), and `+`
 instead of `*` to mean "at least one".
 
 ~~~~
-# enum T { SpecialA(uint),SpecialB(uint),SpecialC(uint),SpecialD(uint)};
+# #![feature(macro_rules)]
+# enum T { SpecialA(uint),SpecialB(uint),SpecialC(uint),SpecialD(uint)}
 # fn f() -> uint {
 # let input_1 = SpecialA(0);
 # let input_2 = SpecialA(0);
@@ -175,6 +178,7 @@ early_return!(input_1, [SpecialA|SpecialC|SpecialD]);
 early_return!(input_2, [SpecialB]);
 # return 0;
 # }
+# fn main() {}
 ~~~~
 
 ### Transcription
@@ -215,9 +219,10 @@ solves the problem.
 Now consider code like the following:
 
 ~~~~
-# enum T1 { Good1(T2, uint), Bad1};
+# #![feature(macro_rules)]
+# enum T1 { Good1(T2, uint), Bad1}
 # struct T2 { body: T3 }
-# enum T3 { Good2(uint), Bad2};
+# enum T3 { Good2(uint), Bad2}
 # fn f(x: T1) -> uint {
 match x {
     Good1(g1, val) => {
@@ -232,6 +237,7 @@ match x {
     _ => return 0 // default value
 }
 # }
+# fn main() {}
 ~~~~
 
 All the complicated stuff is deeply indented, and the error-handling code is
@@ -240,6 +246,7 @@ a match, but with a syntax that suits the problem better. The following macro
 can solve the problem:
 
 ~~~~
+# #![feature(macro_rules)]
 macro_rules! biased_match (
     // special case: `let (x) = ...` is illegal, so use `let x = ...` instead
     ( ($e:expr) ~ ($p:pat) else $err:stmt ;
@@ -261,9 +268,9 @@ macro_rules! biased_match (
     )
 )
 
-# enum T1 { Good1(T2, uint), Bad1};
+# enum T1 { Good1(T2, uint), Bad1}
 # struct T2 { body: T3 }
-# enum T3 { Good2(uint), Bad2};
+# enum T3 { Good2(uint), Bad2}
 # fn f(x: T1) -> uint {
 biased_match!((x)       ~ (Good1(g1, val)) else { return 0 };
               binds g1, val )
@@ -273,13 +280,16 @@ biased_match!((g1.body) ~ (Good2(result) )
 // complicated stuff goes here
 return result + val;
 # }
+# fn main() {}
 ~~~~
 
 This solves the indentation problem. But if we have a lot of chained matches
 like this, we might prefer to write a single macro invocation. The input
 pattern we want is clear:
 
 ~~~~
+# #![feature(macro_rules)]
+# fn main() {}
 # macro_rules! b(
     ( $( ($e:expr) ~ ($p:pat) else $err:stmt ; )*
       binds $( $bind_res:ident ),*
@@ -301,14 +311,18 @@ process the semicolon-terminated lines, one-by-one. So, we want the following
 input patterns:
 
 ~~~~
+# #![feature(macro_rules)]
 # macro_rules! b(
     ( binds $( $bind_res:ident ),* )
 # => (0))
+# fn main() {}
 ~~~~
 
 ...and:
 
 ~~~~
+# #![feature(macro_rules)]
+# fn main() {}
 # macro_rules! b(
     (    ($e     :expr) ~ ($p     :pat) else $err     :stmt ;
       $( ($e_rest:expr) ~ ($p_rest:pat) else $err_rest:stmt ; )*
@@ -322,6 +336,8 @@ The resulting macro looks like this. Note that the separation into
 piece of syntax (the `let`) which we only want to transcribe once.
 
 ~~~~
+# #![feature(macro_rules)]
+# fn main() {
 
 macro_rules! biased_match_rec (
     // Handle the first layer
@@ -365,9 +381,9 @@ macro_rules! biased_match (
 )
 
 
-# enum T1 { Good1(T2, uint), Bad1};
+# enum T1 { Good1(T2, uint), Bad1}
 # struct T2 { body: T3 }
-# enum T3 { Good2(uint), Bad2};
+# enum T3 { Good2(uint), Bad2}
 # fn f(x: T1) -> uint {
 biased_match!(
     (x)       ~ (Good1(g1, val)) else { return 0 };
@@ -376,6 +392,7 @@ biased_match!(
 // complicated stuff goes here
 return result + val;
 # }
+# }
 ~~~~
 
 This technique applies to many cases where transcribing a result all at once is not possible.

branches/try2/src/doc/guide-unsafe.md

@@ -523,6 +523,7 @@ vectors provided from C, using idiomatic Rust practices.
 
 ```
 #![no_std]
+#![feature(globs)]
 
 # extern crate libc;
 extern crate core;

branches/try2/src/doc/rust.css

@@ -313,6 +313,19 @@ table th {
     padding: 5px;
 }
 
+/* Code snippets */
+
+.rusttest { display: none; }
+pre.rust { position: relative; }
+pre.rust a { transform: scaleX(-1); }
+.test-arrow {
+    display: inline-block;
+    position: absolute;
+    top: 0;
+    right: 10px;
+    font-size: 150%;
+}
+
 @media (min-width: 1170px) {
     pre {
         font-size: 15px;

branches/try2/src/doc/rust.md

@@ -1260,13 +1260,16 @@ a = Cat;
 Enumeration constructors can have either named or unnamed fields:
 
 ~~~~
+# #![feature(struct_variant)]
+# fn main() {
 enum Animal {
     Dog (String, f64),
     Cat { name: String, weight: f64 }
 }
 
 let mut a: Animal = Dog("Cocoa".to_string(), 37.2);
 a = Cat { name: "Spotty".to_string(), weight: 2.7 };
+# }
 ~~~~
 
 In this example, `Cat` is a _struct-like enum variant_,
@@ -2524,10 +2527,10 @@ Note that for a given *unit-like* structure type, this will always be the same v
 
 A structure expression can terminate with the syntax `..` followed by an expression to denote a functional update.
 The expression following `..` (the base) must have the same structure type as the new structure type being formed.
-The entire expression denotes the result of allocating a new structure
+The entire expression denotes the result of constructing a new structure
 (with the same type as the base expression)
 with the given values for the fields that were explicitly specified
-and the values in the base record for all other fields.
+and the values in the base expression for all other fields.
 
 ~~~~
 # struct Point3d { x: int, y: int, z: int }
@@ -2575,15 +2578,15 @@ when not immediately followed by a parenthesized expression-list (the latter is
 A field expression denotes a field of a [structure](#structure-types).
 
 ~~~~ {.ignore .field}
-myrecord.myfield;
+mystruct.myfield;
 foo().x;
 (Struct {a: 10, b: 20}).a;
 ~~~~
 
-A field access on a record is an [lvalue](#lvalues-rvalues-and-temporaries) referring to the value of that field.
-When the field is mutable, it can be [assigned](#assignment-expressions) to.
+A field access is an [lvalue](#lvalues-rvalues-and-temporaries) referring to the value of that field.
+When the type providing the field inherits mutabilty, it can be [assigned](#assignment-expressions) to.
 
-When the type of the expression to the left of the dot is a pointer to a record or structure,
+Also, if the type of the expression to the left of the dot is a pointer,
 it is automatically dereferenced to make the field access possible.
 
 ### Vector expressions
@@ -3038,7 +3041,7 @@ match_pat : pat [ '|' pat ] * [ "if" expr ] ? ;
 
 A `match` expression branches on a *pattern*. The exact form of matching that
 occurs depends on the pattern. Patterns consist of some combination of
-literals, destructured vectors or enum constructors, structures, records and
+literals, destructured vectors or enum constructors, structures and
 tuples, variable binding specifications, wildcards (`..`), and placeholders
 (`_`). A `match` expression has a *head expression*, which is the value to
 compare to the patterns. The type of the patterns must equal the type of the
@@ -3315,17 +3318,16 @@ such as `&str` or `String`.
 
 ### Tuple types
 
-The tuple type-constructor forms a new heterogeneous product of values similar
-to the record type-constructor. The differences are as follows:
-
-* tuple elements cannot be mutable, unlike record fields
-* tuple elements are not named and can be accessed only by pattern-matching
+A tuple *type* is a heterogeneous product of other types, called the *elements*
+of the tuple. It has no nominal name and is instead structurally typed.
 
 Tuple types and values are denoted by listing the types or values of their
 elements, respectively, in a parenthesized, comma-separated
 list.
 
-The members of a tuple are laid out in memory contiguously, like a record, in
+Because tuple elements don't have a name, they can only be accessed by pattern-matching.
+
+The members of a tuple are laid out in memory contiguously, in
 order specified by the tuple type.
 
 An example of a tuple type and its use:
@@ -3377,12 +3379,13 @@ of the type.[^structtype]
 
 New instances of a `struct` can be constructed with a [struct expression](#structure-expressions).
 
-The memory order of fields in a `struct` is given by the item defining it.
-Fields may be given in any order in a corresponding struct *expression*;
-the resulting `struct` value will always be laid out in memory in the order specified by the corresponding *item*.
+The memory layout of a `struct` is undefined by default to allow for compiler optimziations like
+field reordering, but it can be fixed with the `#[repr(...)]` attribute.
+In either case, fields may be given in any order in a corresponding struct *expression*;
+the resulting `struct` value will always have the same memory layout.
 
 The fields of a `struct` may be qualified by [visibility modifiers](#re-exporting-and-visibility),
-to restrict access to implementation-private data in a structure.
+to allow access to data in a structure outside a module.
 
 A _tuple struct_ type is just like a structure type, except that the fields are anonymous.
 
@@ -3933,7 +3936,7 @@ The runtime provides C and Rust code to assist with various built-in types,
 such as vectors, strings, and the low level communication system (ports,
 channels, tasks).
 
-Support for other built-in types such as simple types, tuples, records, and
+Support for other built-in types such as simple types, tuples and
 enums is open-coded by the Rust compiler.
 
 ### Task scheduling and communication

branches/try2/src/doc/tutorial.md

@@ -774,6 +774,7 @@ fn point_from_direction(dir: Direction) -> Point {
 Enum variants may also be structs. For example:
 
 ~~~~
+# #![feature(struct_variant)]
 use std::f64;
 # struct Point { x: f64, y: f64 }
 # fn square(x: f64) -> f64 { x * x }
@@ -789,6 +790,7 @@ fn area(sh: Shape) -> f64 {
         }
     }
 }
+# fn main() {}
 ~~~~
 
 > *Note:* This feature of the compiler is currently gated behind the
@@ -3046,6 +3048,7 @@ use farm::{chicken, cow};
 2. Import everything in a module with a wildcard:
 
 ~~~
+# #![feature(globs)]
 use farm::*;
 # mod farm {
 #     pub fn cow() { println!("Bat-chicken? What a stupid name!") }