But don't actually generate code that does the operation. That means
hoisting the check I added in my last commit from trans_compare
up into trans_eager_binop (don't generate any code if one operand
has type _|_ ).
Closes#777
This was at least partially responsible for Issue 777.
The only solution I can think of is for trans to just not generate
code for a comparison if one or both sides has type _|_. Since
that means evaluating that subexpression diverges, it should be ok
to never do the comparison. Actually generating code for the
comparison would trip an LLVM assertion failure.
After running source files through the pretty printer, we sanity check them by
running the results through the compiler with the --no-trans flag. Now also
use the --lib flag so that pretty-printer tests don't have to include a main
function.
Add a new src/test/pretty directory to hold just source files for testing the
pretty-printer.
Add a new pp-exact directive. When this directive is followed by a file name
it specifies a file containing the output that the pretty-printer should
generate. When pp-exact is not followed by a filename it says that the file
should pretty-print as written.
This is required so that assigning to these locals doesn't clobber
the content of the box.
(A possible optimization would be to only do this copying for
locals that actually are assigned to.)
The logic for how the "returns" constraint was handled was always
dodgy, for reasons explained in the comments I added to
auxiliary::fn_info in this commit. Fixed it by adding distinct
"returns" and "diverges" constraints for each function, which
are both handled positively (that is: for a ! function, the
"diverges" constraint must be true on every exit path; for
any other function, the "returns" constraint must be true
on every exit path).
Closes#779
Still working on getting backwarding to play nicely with self and
overriding. Currently can't fix issue #702 without breaking how self
and overriding interact.
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.
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.
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.
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.
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 meant most of the generic-ness of it had to go away, since our
type system doesn't quite support it yet. Hopefully someday...
This version has lots of memory management errors. My next commit will
hopefully fix these.
