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.
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.)
