---

yaml
---
r: 149051
b: refs/heads/try2
c: 882e2c3
h: refs/heads/master
i:
  149049: 3286cab
  149047: 6c5ce38
v: v3

Author: alexcrichton

[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: 47e14456f7993be4924a41a854ebf4f212e171c2
+refs/heads/try2: 882e2c391e9dc0bedb3ffdc549862294cf174ec8
 refs/heads/dist-snap: ba4081a5a8573875fed17545846f6f6902c8ba8d
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try2/mk/crates.mk

@@ -50,7 +50,7 @@
 ################################################################################
 
 TARGET_CRATES := std extra green rustuv native flate arena glob term semver \
-                 uuid serialize sync getopts collections fourcc
+                 uuid serialize sync getopts collections
 HOST_CRATES := syntax rustc rustdoc
 CRATES := $(TARGET_CRATES) $(HOST_CRATES)
 TOOLS := compiletest rustdoc rustc
@@ -74,7 +74,6 @@ DEPS_uuid := std serialize
 DEPS_sync := std
 DEPS_getopts := std
 DEPS_collections := std serialize
-DEPS_fourcc := syntax std
 
 TOOL_DEPS_compiletest := extra green rustuv getopts
 TOOL_DEPS_rustdoc := rustdoc green rustuv

branches/try2/mk/target.mk

@@ -74,7 +74,7 @@ $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$(4):				    \
 		$$(CRATE_FULLDEPS_$(1)_T_$(2)_H_$(3)_$(4))	    \
 		$$(TSREQ$(1)_T_$(2)_H_$(3))			    \
 		| $$(TLIB$(1)_T_$(2)_H_$(3))/
-	@$$(call E, oxidize: $$(@D)/lib$(4))
+	@$$(call E, compile_and_link: $$(@D)/lib$(4))
 	$$(call REMOVE_ALL_OLD_GLOB_MATCHES,\
 	    $$(dir $$@)$$(call CFG_LIB_GLOB_$(2),$(4)))
 	$$(call REMOVE_ALL_OLD_GLOB_MATCHES,\
@@ -113,7 +113,7 @@ $$(TBIN$(1)_T_$(2)_H_$(3))/$(4)$$(X_$(2)):			\
 		    $$(TLIB$(1)_T_$(2)_H_$(3))/stamp.$$(dep))	\
 		$$(TSREQ$(1)_T_$(2)_H_$(3))			\
 		| $$(TBIN$(1)_T_$(4)_H_$(3))/
-	@$$(call E, oxidize: $$@)
+	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --cfg $(4)
 
 endef

branches/try2/mk/tests.mk

@@ -347,7 +347,7 @@ $(3)/stage$(1)/test/$(4)test-$(2)$$(X_$(2)):				\
 		$$(CRATEFILE_$(4))					\
 		$$(CRATE_FULLDEPS_$(1)_T_$(2)_H_$(3)_$(4))		\
 		$$(STDTESTDEP_$(1)_$(2)_$(3)_$(4))
-	@$$(call E, oxidize: $$@)
+	@$$(call E, compile_and_link: $$@)
 	$$(STAGE$(1)_T_$(2)_H_$(3)) -o $$@ $$< --test	\
 		-L "$$(RT_OUTPUT_DIR_$(2))"		\
 		-L "$$(LLVM_LIBDIR_$(2))"
@@ -835,15 +835,15 @@ define DEF_CHECK_FAST_FOR_T_H
 $$(TLIB2_T_$(2)_H_$(3))/$$(FT_LIB): \
 		tmp/$$(FT).rc \
 		$$(SREQ2_T_$(2)_H_$(3))
-	@$$(call E, oxidize: $$@)
+	@$$(call E, compile_and_link: $$@)
 	$$(STAGE2_T_$(2)_H_$(3)) --crate-type=dylib --out-dir $$(@D) $$< \
 	  -L "$$(RT_OUTPUT_DIR_$(2))"
 
 $(3)/test/$$(FT_DRIVER)-$(2)$$(X_$(2)): \
 		tmp/$$(FT_DRIVER).rs \
 		$$(TLIB2_T_$(2)_H_$(3))/$$(FT_LIB) \
 		$$(SREQ2_T_$(2)_H_$(3))
-	@$$(call E, oxidize: $$@ $$<)
+	@$$(call E, compile_and_link: $$@ $$<)
 	$$(STAGE2_T_$(2)_H_$(3)) -o $$@ $$< \
 	  -L "$$(RT_OUTPUT_DIR_$(2))"
 

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

@@ -176,8 +176,8 @@ and `free`:
 ~~~~
 use std::cast;
 use std::libc::{c_void, size_t, malloc, free};
-use std::mem;
 use std::ptr;
+use std::unstable::intrinsics;
 
 // Define a wrapper around the handle returned by the foreign code.
 // Unique<T> has the same semantics as ~T
@@ -199,7 +199,7 @@ impl<T: Send> Unique<T> {
             // `*ptr` is uninitialized, and `*ptr = value` would attempt to destroy it
             // move_val_init moves a value into this memory without
             // attempting to drop the original value.
-            mem::move_val_init(&mut *ptr, value);
+            intrinsics::move_val_init(&mut *ptr, value);
             Unique{ptr: ptr}
         }
     }
@@ -226,7 +226,7 @@ impl<T: Send> Unique<T> {
 impl<T: Send> Drop for Unique<T> {
     fn drop(&mut self) {
         unsafe {
-            let x = mem::uninit(); // dummy value to swap in
+            let x = intrinsics::uninit(); // dummy value to swap in
             // We need to move the object out of the box, so that
             // the destructor is called (at the end of this scope.)
             ptr::replace_ptr(self.ptr, x);

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

@@ -16,12 +16,10 @@ fn return_two_test() {
 }
 ~~~
 
-To run these tests, compile with `rustc --test` and run the resulting
-binary:
+To run these tests, use `rustc --test`:
 
 ~~~ {.notrust}
-$ rustc --test foo.rs
-$ ./foo
+$ rustc --test foo.rs; ./foo
 running 1 test
 test return_two_test ... ok
 
@@ -49,8 +47,8 @@ value. To run the tests in a crate, it must be compiled with the
 `--test` flag: `rustc myprogram.rs --test -o myprogram-tests`. Running
 the resulting executable will run all the tests in the crate. A test
 is considered successful if its function returns; if the task running
-the test fails, through a call to `fail!`, a failed `assert`, or some
-other (`assert_eq`, ...) means, then the test fails.
+the test fails, through a call to `fail!`, a failed `check` or
+`assert`, or some other (`assert_eq`, ...) means, then the test fails.
 
 When compiling a crate with the `--test` flag `--cfg test` is also
 implied, so that tests can be conditionally compiled.
@@ -102,63 +100,7 @@ failure output difficult. In these cases you can set the
 `RUST_TEST_TASKS` environment variable to 1 to make the tests run
 sequentially.
 
-## Examples
-
-### Typical test run
-
-~~~ {.notrust}
-$ mytests
-
-running 30 tests
-running driver::tests::mytest1 ... ok
-running driver::tests::mytest2 ... ignored
-... snip ...
-running driver::tests::mytest30 ... ok
-
-result: ok. 28 passed; 0 failed; 2 ignored
-~~~
-
-### Test run with failures
-
-~~~ {.notrust}
-$ mytests
-
-running 30 tests
-running driver::tests::mytest1 ... ok
-running driver::tests::mytest2 ... ignored
-... snip ...
-running driver::tests::mytest30 ... FAILED
-
-result: FAILED. 27 passed; 1 failed; 2 ignored
-~~~
-
-### Running ignored tests
-
-~~~ {.notrust}
-$ mytests --ignored
-
-running 2 tests
-running driver::tests::mytest2 ... failed
-running driver::tests::mytest10 ... ok
-
-result: FAILED. 1 passed; 1 failed; 0 ignored
-~~~
-
-### Running a subset of tests
-
-~~~ {.notrust}
-$ mytests mytest1
-
-running 11 tests
-running driver::tests::mytest1 ... ok
-running driver::tests::mytest10 ... ignored
-... snip ...
-running driver::tests::mytest19 ... ok
-
-result: ok. 11 passed; 0 failed; 1 ignored
-~~~
-
-# Microbenchmarking
+## Benchmarking
 
 The test runner also understands a simple form of benchmark execution.
 Benchmark functions are marked with the `#[bench]` attribute, rather
@@ -169,12 +111,11 @@ component of your testsuite, pass `--bench` to the compiled test
 runner.
 
 The type signature of a benchmark function differs from a unit test:
-it takes a mutable reference to type
-`extra::test::BenchHarness`. Inside the benchmark function, any
-time-variable or "setup" code should execute first, followed by a call
-to `iter` on the benchmark harness, passing a closure that contains
-the portion of the benchmark you wish to actually measure the
-per-iteration speed of.
+it takes a mutable reference to type `test::BenchHarness`. Inside the
+benchmark function, any time-variable or "setup" code should execute
+first, followed by a call to `iter` on the benchmark harness, passing
+a closure that contains the portion of the benchmark you wish to
+actually measure the per-iteration speed of.
 
 For benchmarks relating to processing/generating data, one can set the
 `bytes` field to the number of bytes consumed/produced in each
@@ -187,16 +128,15 @@ For example:
 ~~~
 extern mod extra;
 use std::vec;
-use extra::test::BenchHarness;
 
 #[bench]
-fn bench_sum_1024_ints(b: &mut BenchHarness) {
+fn bench_sum_1024_ints(b: &mut extra::test::BenchHarness) {
     let v = vec::from_fn(1024, |n| n);
     b.iter(|| {v.iter().fold(0, |old, new| old + *new);} );
 }
 
 #[bench]
-fn initialise_a_vector(b: &mut BenchHarness) {
+fn initialise_a_vector(b: &mut extra::test::BenchHarness) {
     b.iter(|| {vec::from_elem(1024, 0u64);} );
     b.bytes = 1024 * 8;
 }
@@ -223,87 +163,73 @@ Advice on writing benchmarks:
 To run benchmarks, pass the `--bench` flag to the compiled
 test-runner. Benchmarks are compiled-in but not executed by default.
 
+## Examples
+
+### Typical test run
+
 ~~~ {.notrust}
-$ rustc mytests.rs -O --test
-$ mytests --bench
+> mytests
 
-running 2 tests
-test bench_sum_1024_ints ... bench: 709 ns/iter (+/- 82)
-test initialise_a_vector ... bench: 424 ns/iter (+/- 99) = 19320 MB/s
+running 30 tests
+running driver::tests::mytest1 ... ok
+running driver::tests::mytest2 ... ignored
+... snip ...
+running driver::tests::mytest30 ... ok
 
-test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured
-~~~
+result: ok. 28 passed; 0 failed; 2 ignored
+~~~ {.notrust}
 
-## Benchmarks and the optimizer
+### Test run with failures
 
-Benchmarks compiled with optimizations activated can be dramatically
-changed by the optimizer so that the benchmark is no longer
-benchmarking what one expects. For example, the compiler might
-recognize that some calculation has no external effects and remove
-it entirely.
+~~~ {.notrust}
+> mytests
 
-~~~
-extern mod extra;
-use extra::test::BenchHarness;
+running 30 tests
+running driver::tests::mytest1 ... ok
+running driver::tests::mytest2 ... ignored
+... snip ...
+running driver::tests::mytest30 ... FAILED
 
-#[bench]
-fn bench_xor_1000_ints(bh: &mut BenchHarness) {
-    bh.iter(|| {
-            range(0, 1000).fold(0, |old, new| old ^ new);
-        });
-}
+result: FAILED. 27 passed; 1 failed; 2 ignored
 ~~~
 
-gives the following results
+### Running ignored tests
 
 ~~~ {.notrust}
-running 1 test
-test bench_xor_1000_ints ... bench:         0 ns/iter (+/- 0)
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured
-~~~
+> mytests --ignored
 
-The benchmarking runner offers two ways to avoid this. Either, the
-closure that the `iter` method receives can return an arbitrary value
-which forces the optimizer to consider the result used and ensures it
-cannot remove the computation entirely. This could be done for the
-example above by adjusting the `bh.iter` call to
+running 2 tests
+running driver::tests::mytest2 ... failed
+running driver::tests::mytest10 ... ok
 
-~~~
-bh.iter(|| range(0, 1000).fold(0, |old, new| old ^ new))
+result: FAILED. 1 passed; 1 failed; 0 ignored
 ~~~
 
-Or, the other option is to call the generic `extra::test::black_box`
-function, which is an opaque "black box" to the optimizer and so
-forces it to consider any argument as used.
+### Running a subset of tests
 
-~~~
-use extra::test::black_box
+~~~ {.notrust}
+> mytests mytest1
 
-bh.iter(|| {
-        black_box(range(0, 1000).fold(0, |old, new| old ^ new));
-    });
-~~~
+running 11 tests
+running driver::tests::mytest1 ... ok
+running driver::tests::mytest10 ... ignored
+... snip ...
+running driver::tests::mytest19 ... ok
 
-Neither of these read or modify the value, and are very cheap for
-small values. Larger values can be passed indirectly to reduce
-overhead (e.g. `black_box(&huge_struct)`).
+result: ok. 11 passed; 0 failed; 1 ignored
+~~~
 
-Performing either of the above changes gives the following
-benchmarking results
+### Running benchmarks
 
 ~~~ {.notrust}
-running 1 test
-test bench_xor_1000_ints ... bench:       375 ns/iter (+/- 148)
+> mytests --bench
 
-test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured
-~~~
+running 2 tests
+test bench_sum_1024_ints ... bench: 709 ns/iter (+/- 82)
+test initialise_a_vector ... bench: 424 ns/iter (+/- 99) = 19320 MB/s
 
-However, the optimizer can still modify a testcase in an undesirable
-manner even when using either of the above. Benchmarks can be checked
-by hand by looking at the output of the compiler using the `--emit=ir`
-(for LLVM IR), `--emit=asm` (for assembly) or compiling normally and
-using any method for examining object code.
+test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured
+~~~
 
 ## Saving and ratcheting metrics