---

yaml
---
r: 149036
b: refs/heads/try2
c: 3a610e9
h: refs/heads/master
v: v3

Author: gifnksm

[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: 2780d9dd5410a5c093f27eacfb1684ddbfcb4632
+refs/heads/try2: 3a610e98a292f5bc75a720aa15c3600787a5ddb2
 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/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