The resulting code is strange, but perhaps someone else can
fix it. The obvious things, like returning body_res, all resulted
in completely incomprehensible LLVM errors.
Closes#814
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.
trans was failing with a bounds check error because the caller
was using the declared type (an out-of-scope ty param) and not
the actual type in a list of argument types to zero.
Closes#811
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.
Previously, typestate was initializing the init constraint for
a declared-but-not-initialized variable (like x in "let x;") to False,
but other constraints to Don't-know. This led to over-lenient results
when a variable was used before declaration (see the included test
case). Now, everything gets initialized to False in the prestate/poststate-
finding phase, and Don't-know should only be used in pre/postconditions.
This aspect of the algorithm really needs formalization (just on paper),
but for now, this closes#700
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
In the writeback phase, the typechecker now checks that it isn't
replacing a type variable T with a type that contains T. It
also does an occurs check in do_autoderef in order to avoid
getting into an infinite chain of derefs.
I'm a bit worried that there are more places where the occurs
check needs to happen where I'm not doing it now, though.
Closes#768
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.
This reverts commit ea81c03960.
Changed the case in trans_if where the conditional is _|_ - typed
but the block is terminated to return the result of the cond,
instead of nil.
This passes "make check" with optimization disabled as well as
enabled.
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.
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
