---

yaml
---
r: 50942
b: refs/heads/try
c: df171e4
h: refs/heads/master
v: v3

Author: bors

[refs]

@@ -2,7 +2,7 @@
 refs/heads/master: 5f13e9ccc2e3328d4cd8ca49f84e6840dd998346
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
 refs/heads/snap-stage3: f7a2371c176663d59062ec5158f39faecba45768
-refs/heads/try: 057c40d5bd3dc700af7d99a2dfeba0fe6c2ba119
+refs/heads/try: df171e4b6898db92610bcccb22d996d361e16902
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c

branches/try/Makefile.in

@@ -238,7 +238,7 @@ $(foreach target,$(CFG_TARGET_TRIPLES),\
 
 CORELIB_CRATE := $(S)src/libcore/core.rc
 CORELIB_INPUTS := $(wildcard $(addprefix $(S)src/libcore/,        \
-                                           core.rc *.rs */*.rs))
+                                           core.rc *.rs */*.rs */*/*rs))
 
 ######################################################################
 # Standard library variables

branches/try/doc/tutorial-macros.md

@@ -3,10 +3,12 @@
 # Introduction
 
 Functions are the primary tool that programmers can use to build abstractions.
-Sometimes, however, programmers want to perform abstractions over things that are not
-runtime values. Macros provide a syntactic abstraction. For an example of how this
-can be useful, consider the following two code fragments, which both pattern-match
-on their input and return early in one case, and do nothing otherwise:
+Sometimes, however, programmers want to abstract over compile-time syntax
+rather than run-time values.
+Macros provide syntactic abstraction.
+For an example of how this can be useful, consider the following two code fragments,
+which both pattern-match on their input and both return early in one case,
+doing nothing otherwise:
 
 ~~~~
 # enum t { special_a(uint), special_b(uint) };
@@ -25,9 +27,10 @@ match input_2 {
 # }
 ~~~~
 
-This code could become tiresome if repeated many times. However, no function
-can capture its functionality to make it possible to rewrite the repetition
-away. Rust's macro system, however, can eliminate the repetition. Macros are
+This code could become tiresome if repeated many times.
+However, no function can capture its functionality to make it possible
+to abstract the repetition away.
+Rust's macro system, however, can eliminate the repetition. Macros are
 lightweight custom syntax extensions, themselves defined using the
 `macro_rules!` syntax extension. The following `early_return` macro captures
 the pattern in the above code:
@@ -37,7 +40,7 @@ the pattern in the above code:
 # fn f() -> uint {
 # let input_1 = special_a(0), input_2 = special_a(0);
 macro_rules! early_return(
-    ($inp:expr $sp:ident) => ( //invoke it like `(input_5 special_e)`
+    ($inp:expr $sp:ident) => ( // invoke it like `(input_5 special_e)`
         match $inp {
             $sp(x) => { return x; }
             _ => {}
@@ -93,10 +96,10 @@ that could be invoked like: `my_macro!(i->(( 2+2 )))`.
 
 ## Invocation location
 
-A macro invocation may take the place of (and therefore expand to) either an
-expression, an item, or a statement. The Rust parser will parse the macro
-invocation as a "placeholder" for whichever of those three nonterminals is
-appropriate for the location.
+A macro invocation may take the place of (and therefore expand to)
+an expression, an item, or a statement.
+The Rust parser will parse the macro invocation as a "placeholder"
+for whichever of those three nonterminals is appropriate for the location.
 
 At expansion time, the output of the macro will be parsed as whichever of the
 three nonterminals it stands in for. This means that a single macro might,
@@ -112,17 +115,19 @@ The right-hand side of the `=>` follows the same rules as the left-hand side,
 except that a `$` need only be followed by the name of the syntactic fragment
 to transcribe into the macro expansion; its type need not be repeated.
 
-The right-hand side must be enclosed by delimiters, which are ignored by the
-transcriber (therefore `() => ((1,2,3))` is a macro that expands to a tuple
-expression, `() => (let $x=$val)` is a macro that expands to a statement, and
-`() => (1,2,3)` is a macro that expands to a syntax error).
+The right-hand side must be enclosed by delimiters, which the transcriber ignores.
+Therefore `() => ((1,2,3))` is a macro that expands to a tuple expression,
+`() => (let $x=$val)` is a macro that expands to a statement,
+and `() => (1,2,3)` is a macro that expands to a syntax error
+(since the transcriber interprets the parentheses on the right-hand-size as delimiters,
+and `1,2,3` is not a valid Rust expression on its own).
 
 Except for permissibility of `$name` (and `$(...)*`, discussed below), the
 right-hand side of a macro definition is ordinary Rust syntax. In particular,
 macro invocations (including invocations of the macro currently being defined)
 are permitted in expression, statement, and item locations. However, nothing
 else about the code is examined or executed by the macro system; execution
-still has to wait until runtime.
+still has to wait until run-time.
 
 ## Interpolation location
 
@@ -287,7 +292,6 @@ A macro may accept multiple different input grammars. The first one to
 successfully match the actual argument to a macro invocation is the one that
 "wins".
 
-
 In the case of the example above, we want to write a recursive macro to
 process the semicolon-terminated lines, one-by-one. So, we want the following
 input patterns:
@@ -369,19 +373,19 @@ return result + val;
 # }
 ~~~~
 
-This technique is applicable in many cases where transcribing a result "all
-at once" is not possible. It resembles ordinary functional programming in some
-respects, but it is important to recognize the differences.
+This technique applies to many cases where transcribing a result all at once is not possible.
+The resulting code resembles ordinary functional programming in some respects,
+but has some important differences from functional programming.
 
 The first difference is important, but also easy to forget: the transcription
 (right-hand) side of a `macro_rules!` rule is literal syntax, which can only
 be executed at run-time. If a piece of transcription syntax does not itself
 appear inside another macro invocation, it will become part of the final
 program. If it is inside a macro invocation (for example, the recursive
-invocation of `biased_match_rec!`), it does have the opprotunity to affect
+invocation of `biased_match_rec!`), it does have the opportunity to affect
 transcription, but only through the process of attempted pattern matching.
 
-The second difference is related: the evaluation order of macros feels
+The second, related, difference is that the evaluation order of macros feels
 "backwards" compared to ordinary programming. Given an invocation
 `m1!(m2!())`, the expander first expands `m1!`, giving it as input the literal
 syntax `m2!()`. If it transcribes its argument unchanged into an appropriate

branches/try/mk/tests.mk

@@ -244,21 +244,29 @@ $(foreach host,$(CFG_HOST_TRIPLES), \
 
 define TEST_RUNNER
 
+# If NO_REBUILD is set then break the dependencies on std so we can
+# test crates without rebuilding core and std first
+ifeq ($(NO_REBUILD),)
+STDTESTDEP_$(1)_$(2)_$(3) = $$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+else
+STDTESTDEP_$(1)_$(2)_$(3) =
+endif
+
 $(3)/test/coretest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(CORELIB_CRATE) $$(CORELIB_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 
 $(3)/test/stdtest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(STDLIB_CRATE) $$(STDLIB_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 
 $(3)/test/syntaxtest.stage$(1)-$(2)$$(X_$(2)):			\
 		$$(LIBSYNTAX_CRATE) $$(LIBSYNTAX_INPUTS)	\
-		$$(TLIB$(1)_T_$(2)_H_$(3))/$$(CFG_STDLIB_$(2))
+		$$(STDTESTDEP_$(1)_$(2)_$(3))
 	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test
 

branches/try/src/compiletest/common.rs

@@ -63,6 +63,9 @@ pub struct config {
     // Run tests using the JIT
     jit: bool,
 
+    // Run tests using the new runtime
+    newrt: bool,
+
     // Explain what's going on
     verbose: bool
 

branches/try/src/compiletest/compiletest.rc

@@ -61,7 +61,8 @@ pub fn parse_config(args: ~[~str]) -> config {
           getopts::optopt(~"runtool"), getopts::optopt(~"rustcflags"),
           getopts::optflag(~"verbose"),
           getopts::optopt(~"logfile"),
-          getopts::optflag(~"jit")];
+          getopts::optflag(~"jit"),
+          getopts::optflag(~"newrt")];
 
     fail_unless!(!args.is_empty());
     let args_ = vec::tail(args);
@@ -95,6 +96,7 @@ pub fn parse_config(args: ~[~str]) -> config {
         runtool: getopts::opt_maybe_str(matches, ~"runtool"),
         rustcflags: getopts::opt_maybe_str(matches, ~"rustcflags"),
         jit: getopts::opt_present(matches, ~"jit"),
+        newrt: getopts::opt_present(matches, ~"newrt"),
         verbose: getopts::opt_present(matches, ~"verbose")
     }
 }
@@ -114,6 +116,7 @@ pub fn log_config(config: config) {
     logv(c, fmt!("runtool: %s", opt_str(config.runtool)));
     logv(c, fmt!("rustcflags: %s", opt_str(config.rustcflags)));
     logv(c, fmt!("jit: %b", config.jit));
+    logv(c, fmt!("newrt: %b", config.newrt));
     logv(c, fmt!("verbose: %b", config.verbose));
     logv(c, fmt!("\n"));
 }

branches/try/src/compiletest/runtest.rs

@@ -484,9 +484,17 @@ fn compile_test_(config: config, props: TestProps,
 
 fn exec_compiled_test(config: config, props: TestProps,
                       testfile: &Path) -> ProcRes {
+
+    // If testing the new runtime then set the RUST_NEWRT env var
+    let env = if config.newrt {
+        props.exec_env + ~[(~"RUST_NEWRT", ~"1")]
+    } else {
+        props.exec_env
+    };
+
     compose_and_run(config, testfile,
                     make_run_args(config, props, testfile),
-                    props.exec_env,
+                    env,
                     config.run_lib_path, None)
 }
 

branches/try/src/libcore/rt/context.rs

@@ -8,6 +8,7 @@
 // option. This file may not be copied, modified, or distributed
 // except according to those terms.
 
+use option::*;
 use super::stack::StackSegment;
 use libc::c_void;
 use cast::{transmute, transmute_mut_unsafe,
@@ -16,17 +17,30 @@ use cast::{transmute, transmute_mut_unsafe,
 // XXX: Registers is boxed so that it is 16-byte aligned, for storing
 // SSE regs.  It would be marginally better not to do this. In C++ we
 // use an attribute on a struct.
-pub struct Context(~Registers);
+// XXX: It would be nice to define regs as `~Option<Registers>` since
+// the registers are sometimes empty, but the discriminant would
+// then misalign the regs again.
+pub struct Context {
+    /// The context entry point, saved here for later destruction
+    start: Option<~~fn()>,
+    /// Hold the registers while the task or scheduler is suspended
+    regs: ~Registers
+}
 
 pub impl Context {
     fn empty() -> Context {
-        Context(new_regs())
+        Context {
+            start: None,
+            regs: new_regs()
+        }
     }
 
     /// Create a new context that will resume execution by running ~fn()
-    /// # Safety Note
-    /// The `start` closure must remain valid for the life of the Task
-    fn new(start: &~fn(), stack: &mut StackSegment) -> Context {
+    fn new(start: ~fn(), stack: &mut StackSegment) -> Context {
+        // XXX: Putting main into a ~ so it's a thin pointer and can
+        // be passed to the spawn function.  Another unfortunate
+        // allocation
+        let start = ~start;
 
         // The C-ABI function that is the task entry point
         extern fn task_start_wrapper(f: &~fn()) { (*f)() }
@@ -40,21 +54,29 @@ pub impl Context {
         // which we will then modify to call the given function when restored
         let mut regs = new_regs();
         unsafe {
-            swap_registers(transmute_mut_region(&mut *regs),
-                           transmute_region(&*regs))
+            swap_registers(transmute_mut_region(&mut *regs), transmute_region(&*regs))
         };
 
         initialize_call_frame(&mut *regs, fp, argp, sp);
 
-        return Context(regs);
+        return Context {
+            start: Some(start),
+            regs: regs
+        }
     }
 
+    /* Switch contexts
+
+    Suspend the current execution context and resume another by
+    saving the registers values of the executing thread to a Context
+    then loading the registers from a previously saved Context.
+    */
     fn swap(out_context: &mut Context, in_context: &Context) {
         let out_regs: &mut Registers = match out_context {
-            &Context(~ref mut r) => r
+            &Context { regs: ~ref mut r, _ } => r
         };
         let in_regs: &Registers = match in_context {
-            &Context(~ref r) => r
+            &Context { regs: ~ref r, _ } => r
         };
 
         unsafe { swap_registers(out_regs, in_regs) };
@@ -84,11 +106,10 @@ fn new_regs() -> ~Registers {
 }
 
 #[cfg(target_arch = "x86")]
-fn initialize_call_frame(regs: &mut Registers,
-                         fptr: *c_void, arg: *c_void, sp: *mut uint) {
+fn initialize_call_frame(regs: &mut Registers, fptr: *c_void, arg: *c_void, sp: *mut uint) {
 
     let sp = align_down(sp);
-    let sp = mut_offset(sp, -4); // XXX: -4 words? Needs this be done at all?
+    let sp = mut_offset(sp, -4);
 
     unsafe { *sp = arg as uint; }
     let sp = mut_offset(sp, -1);
@@ -108,8 +129,7 @@ type Registers = [uint * 22];
 fn new_regs() -> ~Registers { ~[0, .. 22] }
 
 #[cfg(target_arch = "x86_64")]
-fn initialize_call_frame(regs: &mut Registers,
-                         fptr: *c_void, arg: *c_void, sp: *mut uint) {
+fn initialize_call_frame(regs: &mut Registers, fptr: *c_void, arg: *c_void, sp: *mut uint) {
 
     // Redefinitions from regs.h
     static RUSTRT_ARG0: uint = 3;
@@ -143,8 +163,7 @@ type Registers = [uint * 32];
 fn new_regs() -> ~Registers { ~[0, .. 32] }
 
 #[cfg(target_arch = "arm")]
-fn initialize_call_frame(regs: &mut Registers,
-                         fptr: *c_void, arg: *c_void, sp: *mut uint) {
+fn initialize_call_frame(regs: &mut Registers, fptr: *c_void, arg: *c_void, sp: *mut uint) {
     let sp = mut_offset(sp, -1);
 
     // The final return address. 0 indicates the bottom of the stack
@@ -162,8 +181,7 @@ type Registers = [uint * 32];
 fn new_regs() -> ~Registers { ~[0, .. 32] }
 
 #[cfg(target_arch = "mips")]
-fn initialize_call_frame(regs: &mut Registers,
-                         fptr: *c_void, arg: *c_void, sp: *mut uint) {
+fn initialize_call_frame(regs: &mut Registers, fptr: *c_void, arg: *c_void, sp: *mut uint) {
     let sp = mut_offset(sp, -1);
 
     // The final return address. 0 indicates the bottom of the stack

branches/try/src/libcore/rt/io/file.rs

@@ -0,0 +1,45 @@
+// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
+// file at the top-level directory of this distribution and at
+// http://rust-lang.org/COPYRIGHT.
+//
+// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
+// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
+// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
+// option. This file may not be copied, modified, or distributed
+// except according to those terms.
+
+use prelude::*;
+use super::super::sched::*;
+use super::super::rtio::*;
+use super::Stream;
+
+pub struct FileStream;
+
+pub impl FileStream {
+    fn new(_path: Path) -> FileStream {
+        fail!()
+    }
+}
+
+impl Stream for FileStream {
+    fn read(&mut self, _buf: &mut [u8]) -> uint {
+        fail!()
+    }
+
+    fn eof(&mut self) -> bool {
+        fail!()
+    }
+
+    fn write(&mut self, _v: &const [u8]) {
+        fail!()
+    }
+}
+
+#[test]
+#[ignore]
+fn super_simple_smoke_test_lets_go_read_some_files_and_have_a_good_time() {
+    let message = "it's alright. have a good time";
+    let filename = Path("test.txt");
+    let mut outstream = FileStream::new(filename);
+    outstream.write(message.to_bytes());
+}