rust/src/test/run-pass/unify-return-ty.rs
Tim Chevalier d7ee55bfd0 (Almost) Always unify a function tail expr with the function result type
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.
2011-08-05 02:21:58 -07:00

11 lines
248 B
Rust

// Tests that the tail expr in null() has its type
// unified with the type *T, and so the type variable
// in that type gets resolved.
use std;
import std::unsafe;
fn null[T]() -> *T { unsafe::reinterpret_cast(0) }
fn main() {
null[int]();
}