The way pipes work in windows is not the same as unix, though I'm not
entirely clear on the differences. This patch changes the windows pipe
method to return non-inheritable fds, and the windows rust_run_program
method to duplicate them before spawning the new process.
This allows make-check-pretty to work on windows.
So the test runner displays the name of the test, then waits for it to finish,
then displays the result. It worked this way before things were parallelized
and it's just much friendlier this way.
You can now say
let {bcx, val} = some_result_returner();
Similar for loop variables. Assigning to such variables is not safe
yet. Function arguments also remain a TODO.
Ideally we would just spawn every test and collect the results but I'm not
entirely comfortable doing that yet for reasons that I'm too tired to remember
right now. Urgh.
that absolutely will not succeed with a large default stack. This
should be removed once we have stack grown working.
Also updated word-count to succeed under the new test framework.
In theory. There's still something leaking but I hope it's no longer due to
the test runner doing unsafe things.
This is a pretty nasty patch, working around limitations in the type and task
systems, and it makes the std::test API a little uglier.
It takes a lot of boilerplate to create a task and establish a way to talk to
it. This function simplifies that, allowing you to write something like
'worker(f).chan <| start'. Implementation is very unsafe and only works for a
few types of channels, but something like this is very useful.
This replaces the make-based test runner with a set of Rust-based test
runners. I believe that all existing functionality has been
preserved. The primary objective is to dogfood the Rust test
framework.
A few main things happen here:
1) The run-pass/lib-* tests are all moved into src/test/stdtest. This
is a standalone test crate intended for all standard library tests. It
compiles to build/test/stdtest.stageN.
2) rustc now compiles into yet another build artifact, this one a test
runner that runs any tests contained directly in the rustc crate. This
allows much more fine-grained unit testing of the compiler. It
compiles to build/test/rustctest.stageN.
3) There is a new custom test runner crate at src/test/compiletest
that reproduces all the functionality for running the compile-fail,
run-fail, run-pass and bench tests while integrating with Rust's test
framework. It compiles to build/test/compiletest.stageN.
4) The build rules have been completely changed to use the new test
runners, while also being less redundant, following the example of the
recent stageN.mk rewrite.
It adds two new features to the cfail/rfail/rpass/bench tests:
1) Tests can specify multiple 'error-pattern' directives which must be
satisfied in order.
2) Tests can specify a 'compile-flags' directive which will make the
test runner provide additional command line arguments to rustc.
There are some downsides, the primary being that Rust has to be
functioning pretty well just to run _any_ tests, which I imagine will
be the source of some frustration when the entire test suite
breaks. Will also cause some headaches during porting.
Not having individual make rules, each rpass, etc test no longer
remembers between runs whether it completed successfully. As a result,
it's not possible to incrementally fix multiple tests by just running
'make check', fixing a test, and repeating without re-running all the
tests contained in the test runner. Instead you can filter just the
tests you want to run by using the TESTNAME environment variable.
This also dispenses with the ability to run stage0 tests, but they
tended to be broken more often than not anyway.
Updated the MapReduce protocol so that it's correct more often. It's
still not perfect, but the bugs repro less often now.
Also found a race condition in channel sending. The problem is that
send and receive both need to refer to the _unread field in
circular_buffer. For now I just grabbed the port lock to send. We can
probably get around this by using atomics instead.
This is just until unwinding works. Adds a flag to the runtime to turn
the memory leak checks on task destruction into warnings instead of fatal
errors. I am so sorry.
Issue #428
