---

yaml
---
r: 48090
b: refs/heads/incoming
c: 826644e
h: refs/heads/master
v: v3

Author: bors

[refs]

@@ -6,7 +6,7 @@ refs/heads/try: 2a8fb58d79e685d5ca07b039badcf2ae3ef077ea
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b
 refs/heads/try2: 147ecfdd8221e4a4d4e090486829a06da1e0ca3c
-refs/heads/incoming: 542119f61f376fa71bfc4b34fbb25be604279dc4
+refs/heads/incoming: 826644e8cb37363a4e44561a498e79acfeb77b6a
 refs/heads/dist-snap: 8b98e5a296d95c5e832db0756828e5bec31c6f50
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/incoming/doc/rust.md

@@ -1360,7 +1360,7 @@ Functions within foreign modules are declared in the same way as other Rust func
 with the exception that they may not have a body and are instead terminated by a semicolon.
 
 ~~~
-# use core::libc::{c_char, FILE};
+# use libc::{c_char, FILE};
 # #[nolink]
 
 extern mod c {

branches/incoming/doc/tutorial-ffi.md

@@ -14,7 +14,7 @@ should compile and run without any extra effort.
 
 ~~~~ {.xfail-test}
 extern mod std;
-use core::libc::c_uint;
+use libc::c_uint;
 
 extern mod crypto {
     fn SHA1(src: *u8, sz: c_uint, out: *u8) -> *u8;
@@ -217,7 +217,7 @@ microsecond-resolution timer.
 
 ~~~~
 extern mod std;
-use core::libc::c_ulonglong;
+use libc::c_ulonglong;
 
 struct timeval {
     tv_sec: c_ulonglong,

branches/incoming/doc/tutorial-tasks.md

@@ -80,8 +80,8 @@ calling the `spawn` function with a closure argument. `spawn` executes the
 closure in the new task.
 
 ~~~~
-# use core::io::println;
-use core::task::spawn;
+# use io::println;
+use task::spawn;
 
 // Print something profound in a different task using a named function
 fn print_message() { println("I am running in a different task!"); }
@@ -110,8 +110,8 @@ execution. Like any closure, the function passed to `spawn` may capture
 an environment that it carries across tasks.
 
 ~~~
-# use core::io::println;
-# use core::task::spawn;
+# use io::println;
+# use task::spawn;
 # fn generate_task_number() -> int { 0 }
 // Generate some state locally
 let child_task_number = generate_task_number();
@@ -127,8 +127,8 @@ in parallel. Thus, on a multicore machine, running the following code
 should interleave the output in vaguely random order.
 
 ~~~
-# use core::io::print;
-# use core::task::spawn;
+# use io::print;
+# use task::spawn;
 
 for int::range(0, 20) |child_task_number| {
     do spawn {
@@ -156,8 +156,8 @@ endpoint. Consider the following example of calculating two results
 concurrently:
 
 ~~~~
-use core::task::spawn;
-use core::comm::{stream, Port, Chan};
+use task::spawn;
+use comm::{stream, Port, Chan};
 
 let (port, chan): (Port<int>, Chan<int>) = stream();
 
@@ -178,7 +178,7 @@ stream for sending and receiving integers (the left-hand side of the `let`,
 a tuple into its component parts).
 
 ~~~~
-# use core::comm::{stream, Chan, Port};
+# use comm::{stream, Chan, Port};
 let (port, chan): (Port<int>, Chan<int>) = stream();
 ~~~~
 
@@ -187,8 +187,9 @@ which will wait to receive the data on the port. The next statement
 spawns the child task.
 
 ~~~~
-# use core::task::spawn;
-# use core::comm::{stream, Port, Chan};
+# use task::{spawn};
+# use task::spawn;
+# use comm::{stream, Port, Chan};
 # fn some_expensive_computation() -> int { 42 }
 # let (port, chan) = stream();
 do spawn || {
@@ -208,7 +209,7 @@ computation, then waits for the child's result to arrive on the
 port:
 
 ~~~~
-# use core::comm::{stream, Port, Chan};
+# use comm::{stream, Port, Chan};
 # fn some_other_expensive_computation() {}
 # let (port, chan) = stream::<int>();
 # chan.send(0);
@@ -223,8 +224,8 @@ example needed to compute multiple results across a number of tasks? The
 following program is ill-typed:
 
 ~~~ {.xfail-test}
-# use core::task::{spawn};
-# use core::comm::{stream, Port, Chan};
+# use task::{spawn};
+# use comm::{stream, Port, Chan};
 # fn some_expensive_computation() -> int { 42 }
 let (port, chan) = stream();
 
@@ -243,8 +244,8 @@ Instead we can use a `SharedChan`, a type that allows a single
 `Chan` to be shared by multiple senders.
 
 ~~~
-# use core::task::spawn;
-use core::comm::{stream, SharedChan};
+# use task::spawn;
+use comm::{stream, SharedChan};
 
 let (port, chan) = stream();
 let chan = SharedChan(chan);
@@ -276,8 +277,8 @@ illustrate the point. For reference, written with multiple streams, it
 might look like the example below.
 
 ~~~
-# use core::task::spawn;
-# use core::comm::{stream, Port, Chan};
+# use task::spawn;
+# use comm::{stream, Port, Chan};
 
 // Create a vector of ports, one for each child task
 let ports = do vec::from_fn(3) |init_val| {
@@ -308,7 +309,7 @@ All tasks are, by default, _linked_ to each other. That means that the fates
 of all tasks are intertwined: if one fails, so do all the others.
 
 ~~~
-# use core::task::spawn;
+# use task::spawn;
 # fn do_some_work() { loop { task::yield() } }
 # do task::try {
 // Create a child task that fails
@@ -392,8 +393,8 @@ internally, with additional logic to wait for the child task to finish
 before returning. Hence:
 
 ~~~
-# use core::comm::{stream, Chan, Port};
-# use core::task::{spawn, try};
+# use comm::{stream, Chan, Port};
+# use task::{spawn, try};
 # fn sleep_forever() { loop { task::yield() } }
 # do task::try {
 let (receiver, sender): (Port<int>, Chan<int>) = stream();
@@ -488,8 +489,8 @@ response itself is simply the stringified version of the received value,
 Here is the code for the parent task:
 
 ~~~~
-# use core::task::spawn;
 # use std::comm::DuplexStream;
+# use task::spawn;
 # fn stringifier(channel: &DuplexStream<~str, uint>) {
 #     let mut value: uint;
 #     loop {

branches/incoming/doc/tutorial.md

@@ -1313,7 +1313,7 @@ and [`core::str`]. Here are some examples.
 [`core::str`]: core/str.html
 
 ~~~
-# use core::io::println;
+# use io::println;
 # enum Crayon {
 #     Almond, AntiqueBrass, Apricot,
 #     Aquamarine, Asparagus, AtomicTangerine,
@@ -1368,7 +1368,7 @@ Rust also supports _closures_, functions that can access variables in
 the enclosing scope.
 
 ~~~~
-# use println = core::io::println;
+# use println = io::println;
 fn call_closure_with_ten(b: fn(int)) { b(10); }
 
 let captured_var = 20;
@@ -1525,7 +1525,7 @@ words, it is a function that takes an owned closure that takes no
 arguments.
 
 ~~~~
-use core::task::spawn;
+use task::spawn;
 
 do spawn() || {
     debug!("I'm a task, whatever");
@@ -1537,7 +1537,7 @@ lists back to back. Since that is so unsightly, empty argument lists
 may be omitted from `do` expressions.
 
 ~~~~
-# use core::task::spawn;
+# use task::spawn;
 do spawn {
    debug!("Kablam!");
 }
@@ -1568,8 +1568,8 @@ fn each(v: &[int], op: fn(v: &int) -> bool) {
 And using this function to iterate over a vector:
 
 ~~~~
-# use each = core::vec::each;
-# use println = core::io::println;
+# use each = vec::each;
+# use println = io::println;
 each([2, 4, 8, 5, 16], |n| {
     if *n % 2 != 0 {
         println("found odd number!");
@@ -1585,8 +1585,8 @@ out of the loop, you just write `break`. To skip ahead
 to the next iteration, write `loop`.
 
 ~~~~
-# use each = core::vec::each;
-# use println = core::io::println;
+# use each = vec::each;
+# use println = io::println;
 for each([2, 4, 8, 5, 16]) |n| {
     if *n % 2 != 0 {
         println("found odd number!");
@@ -1601,7 +1601,7 @@ normally allowed in closures, in a block that appears as the body of a
 the enclosing function, not just the loop body.
 
 ~~~~
-# use each = core::vec::each;
+# use each = vec::each;
 fn contains(v: &[int], elt: int) -> bool {
     for each(v) |x| {
         if (*x == elt) { return true; }
@@ -1616,7 +1616,7 @@ In these situations it can be convenient to lean on Rust's
 argument patterns to bind `x` to the actual value, not the pointer.
 
 ~~~~
-# use each = core::vec::each;
+# use each = vec::each;
 # fn contains(v: &[int], elt: int) -> bool {
     for each(v) |&x| {
         if (x == elt) { return true; }
@@ -1758,8 +1758,8 @@ Constructors are one common application for static methods, as in `new` above.
 To call a static method, you have to prefix it with the type name and a double colon:
 
 ~~~~
-# use core::float::consts::pi;
-# use core::float::sqrt;
+# use float::consts::pi;
+# use float::sqrt;
 struct Circle { radius: float }
 impl Circle {
     static fn new(area: float) -> Circle { Circle { radius: sqrt(area / pi) } }
@@ -2030,8 +2030,8 @@ The compiler will use type inference to decide which implementation to call.
 
 ~~~~
 trait Shape { static fn new(area: float) -> Self; }
-# use core::float::consts::pi;
-# use core::float::sqrt;
+# use float::consts::pi;
+# use float::sqrt;
 struct Circle { radius: float }
 struct Square { length: float }
 
@@ -2189,8 +2189,8 @@ Now, we can implement `Circle` on a type only if we also implement `Shape`.
 # trait Shape { fn area(&self) -> float; }
 # trait Circle : Shape { fn radius(&self) -> float; }
 # struct Point { x: float, y: float }
-# use core::float::consts::pi;
-# use core::float::sqrt;
+# use float::consts::pi;
+# use float::sqrt;
 # fn square(x: float) -> float { x * x }
 struct CircleStruct { center: Point, radius: float }
 impl Circle for CircleStruct {
@@ -2224,8 +2224,8 @@ Likewise, supertrait methods may also be called on trait objects.
 ~~~ {.xfail-test}
 # trait Shape { fn area(&self) -> float; }
 # trait Circle : Shape { fn radius(&self) -> float; }
-# use core::float::consts::pi;
-# use core::float::sqrt;
+# use float::consts::pi;
+# use float::sqrt;
 # struct Point { x: float, y: float }
 # struct CircleStruct { center: Point, radius: float }
 # impl Circle for CircleStruct { fn radius(&self) -> float { sqrt(self.area() / pi) } }

branches/incoming/src/compiletest/compiletest.rc

@@ -22,18 +22,18 @@ extern mod std(vers = "0.6");
 
 use core::*;
 
-pub mod procsrv;
-pub mod util;
-pub mod header;
-pub mod runtest;
-pub mod common;
-pub mod errors;
+mod procsrv;
+mod util;
+mod header;
+mod runtest;
+mod common;
+mod errors;
 
 use std::getopts;
 use std::test;
 
 use core::{result, either};
-use core::result::{Ok, Err};
+use result::{Ok, Err};
 
 use common::config;
 use common::mode_run_pass;

branches/incoming/src/compiletest/errors.rs

@@ -11,10 +11,9 @@
 use core::prelude::*;
 
 use common::config;
-
-use core::io;
-use core::io::ReaderUtil;
-use core::str;
+use io;
+use io::ReaderUtil;
+use str;
 
 pub struct ExpectedError { line: uint, kind: ~str, msg: ~str }
 

branches/incoming/src/compiletest/header.rs

@@ -12,11 +12,10 @@ use core::prelude::*;
 
 use common;
 use common::config;
-
-use core::io::ReaderUtil;
-use core::io;
-use core::os;
-use core::str;
+use io;
+use io::ReaderUtil;
+use os;
+use str;
 
 pub struct TestProps {
     // Lines that should be expected, in order, on standard out

branches/incoming/src/compiletest/procsrv.rs

@@ -10,17 +10,17 @@
 
 use core::prelude::*;
 
-use core::io::{ReaderUtil, WriterUtil};
-use core::io;
-use core::libc::{c_int, pid_t};
-use core::libc;
-use core::os;
-use core::pipes;
-use core::run::spawn_process;
-use core::run;
-use core::str;
-use core::task;
-use core::vec;
+use io;
+use io::{ReaderUtil, WriterUtil};
+use libc;
+use libc::{c_int, pid_t};
+use os;
+use run;
+use run::spawn_process;
+use pipes;
+use str;
+use task;
+use vec;
 
 #[cfg(target_os = "win32")]
 fn target_env(lib_path: ~str, prog: ~str) -> ~[(~str,~str)] {