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
The bulk of check_expr is now check_expr_with_unifier, which takes an
expected type and a unification function and will perform the
unification on the type it produces. check_expr calls
check_expr_with_unifier with a dummy unifier and a new function,
check_expr_with, takes an expected type and uses the simple unifier.
I think this generally makes thing cleaner, but the purpose for doing
this is to enable type inferred lambda-blocks to be useful by allowing
the argument types to be unified before the body of the lambda is
checked.
This actually basically makes things worse, since we get less nice
type system guarentees but it will make doing type inferred blocks a
fair deal less painful. I'm not /really/ happy about this...
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
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.
