using them yet. Also, refactor process_fwding_mthd into separate
functions to handle backwarding and forwarding, and refactor
create_vtbl to be more digestible.
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
Use type_contains_vars in occurs_check_fails to avoid doing
any work most of the time. This fixes a performance regression.
(No one else noticed yet that typechecking just got 4x slower, right?
Well, now it isn't anymore. :-})
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
This reverts commit ea81c03960264bf590cd99ed2b662243e3db7a7c.
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.
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.)
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
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.
