Vectors are now similar to our old, pre-internal vectors, except that
they are uniquely owned, not refcounted.
Their name should probably change too, then. I've renamed them to vec
in the runtime, will do so throughout the compiler later.
The syntax is
alt x {
mypat where mycond { ... }
}
The condition may refer to any of the variables bound by the pattern.
When a guard fails, pattern-matching continues with the next pattern.
Closes#857
This makes it easier for the caller to optimize the take/drop away for
temporary values, and opens up new possibilities for alias handling.
Breaks tail calls.
Autoderef on binops is basically unused, kind of silly, and
complicates typechecking. There were only three instances of it in the
compiler and the test drivers, two of which were of the form "*foo =
foo + 1", which should be written as "*foo += 1" anyways.
I tried to pay attention to what was actually being tested so, e.g. when I
test was just using a vec as a boxed thing, I converted to boxed ints, etc.
Haven't converted the macro tests yet. Not sure what to do there.
Un-XFAIL, and just comment out and add a FIXME to the two cases that fail on
linux.
Closes#577. This still doesn't compare <, >, etc for channels, ports and
tasks, but since they use pointer equality, that's a bit difficult to set up.
This is the new way to refer to tasks in rust-land. Currently all they
do is serve as a key to look up the old rust_task structure. Ideally
they won't be ref counted, but baby steps.
typeck::check_fn had an exception for the case where the tail expr
was compatible with type nil -- in that case, it doesn't unify the
tail expr's type with the enclosing function's result type. This
seems wrong to me. There are several test cases in Issue #719
that illustrate why. If the tail expr has type T, for some type
variable T that isn't resolved when this check happens, then T
never gets unified with anything, which is incorrect -- T should
be unified with the result type of the enclosing function. (The
bug was occurring because an unconstrained type variable is
compatible with type nil.)
Instead, I removed the check for type nil and added a check that
the function isn't an iterator -- if it's an iterator, I don't
check the tail expr's type against the function result type,
as that wouldn't make sense.
However, this broke two test cases, and after discussion with
brson, I understood that the purpose of the check was to allow
semicolons to be omitted in some cases. The whole thing seems
rather ad hoc. But I came up with a hacky compromise solution:
instead of checking whether the tailexpr type is *compatible*
with nil, we now just check whether it *is* nil. This also
necessitates calling resolve_type_vars_if_possible before
the check happens, which worries me. But, this fixes the bug
from Issue #719 without requiring changes to any test cases.
Closes#719 but I didn't try every variation -- so reopen the bug
if one of the variations still doesn't work.
Return the result of the discriminant from trans_alt,
rather than nil, in the _|_ case. This was breaking the
enclosed test case (alt-bot-2) when optimization was disabled.
Closes#769
While it is still technically possible to test stage 0, it is not part of any
of the main testing rules and maintaining xfail-stage0 is a chore. Nobody
should worry about how tests fare in stage0.
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.
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.)
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.
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.
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.
We're trying to get closer to doing correct move semantics for channel
operations. This involves a lot of cleanup (such as removing the
unused sched parameter from rust_vec constructor) and making
circular_buffer kernel_owned.
Added tagging for memory allocations. This means we give a string tag
to everything we allocate. If we leak something and TRACK_ALLOCATIONS
is enabled, then it's much easier now to tell exactly what is leaking.
I'm not sure if this is because of changes to glue generation in the
last few days while I've been working on other things, or if it's a
side effect of the improvements I made to typechecking for anonymous
objects, or something else, but I guess I'll take it!
Closes issue #543.
Programs with constrained types now parse and typecheck, but
typestate doesn't check them specially, so the one relevant test
case so far is XFAILed.
Also rewrote all of the constraint-related data structures in the
process (again), for some reason. I got rid of a superfluous
data structure in the context that was mapping front-end constraints
to resolved constraints, instead handling constraints in the same
way in which everything else gets resolved.
This reverts commit 8c94d8fd54.
There's no mechanism to actually return the value from main, so all this does
is allow main -> int to compile. Per #688, the program returns non-zero on
failure, so it's not obvious that this change is appropriate at this time.
ret is similar to fail: if not followed by an expression, it
should be parsed as a ret without an argument. The old version would
fail if ret was followed by a close paren (for example). Fixed it.
Closes#676.
You can now say
expr_move(?dst, ?src) | expr_assign(?dst, ?src) { ... }
to match both expr_move and expr_assign. The names, types, and number
of bound names have to match in all the patterns.
Closes#449.
trans::trans_lval will now autobind if the given expression was the
name of a generic functions. Those callees (trans_call and trans_bind)
that are interested in the generics information call trans_lval_gen
now.
Previously, we were creating both a normal vtable entry and a
forwarding function for overriding methods, when they should have just
gotten a vtable entry. This patch fixes that.
This adds support for dropping cleanups for temporary values when they
are moved somewhere else. It then adds wraps most copy operations
(return, put in data structure, box, etc) in a way that will fall back
to a move when it is safe.
This saves a lot of taking/dropping, shaving over a megabyte off the
stage2/rustc binary size.
In some cases, most notably function returns, we could detect that the
returned value is a local variable, and can thus be safely moved even
though it is not a temporary. This will require putting some more
information in lvals.
I did not yet handle function arguments, since the logic for passing
them looked too convoluted to touch. I'll probably try that in the
near future, since it's bound to be a big win.
