| Age | Commit message (Collapse) | Author | Lines |
|
Takes a lot of workarounds. The biggest problem is that boxes still don't seem
to be moved across channels and bad things happen when the receiver destroys
them. So there's all sorts of defensive cloning and scoping going on here to
make the box lifetimes come out right.
|
|
|
|
and libstd.
|
|
|
|
|
|
The compiler would blow up when compiling a structural type
containing a resource.
|
|
|
|
|
|
|
|
appears to give us much better parallel performance.
Also, commented out one more unsafe log and updated rust_kernel.cpp to compile under g++
|
|
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.
|
|
|
|
Tasks are spawned on a random thread. Currently they stay there, but
we should add task migration and load balancing in the future. This
should drammatically improve our task performance benchmarks.
|
|
|
|
|
|
|
|
|
|
Since compiletest is setting up its own test tasks it needs to configure them
the correct way, which means allowing them to leak.
|
|
|
|
|
|
|
|
This was previously disallowed by the typechecker and not properly handled
in trans. I removed the typechecker check (replacing it with a simpler
check that spawned functions don't have type params) and fixed trans.
Closes #756.
|
|
This commit just disables the check. All of the real work was in previous
commits that moved the target function into the bindings part of the closure
that is tracked by the tydesc.
Closes #754.
|
|
|
|
|
|
It was too unsafe to live. It already apeared to be causing problems with
eholk's incoming task changes, so I'm killing it now before it can spread.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Putting shared boxes into a closure then running that closure in parallel
tasks seems like a recipe for refcounting disaster.
This doesn't completely fix the problems when running in parallel, but I'm
working on it.
|
|
|
|
This avoids a race wherein test tasks could run processes that stole the
environment of other tasks's processes.
|
|
|
|
Closes #745
|
|
|
|
|
|
|
|
|
|
|
|
Closes #732
|
|
|
|
|
|
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.
|