rust/src/test/run-pass/unify-return-ty.rs

// 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.
extern mod std;

fn null<T>() -> *T unsafe { cast::reinterpret_cast(&0) }

fn main() { null::<int>(); }
(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-04 18:34:05 -07:00			`// 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.`
Convert 'use' to 'extern mod'. Remove old 'use' syntax 2012-09-11 17:46:20 -07:00			`extern mod std;`
(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-04 18:34:05 -07:00
core: Rename 'unsafe' mod to 'cast' 2012-09-18 17:34:08 -07:00			`fn null<T>() -> *T unsafe { cast::reinterpret_cast(&0) }`
(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-04 18:34:05 -07:00
Reformat This changes the indexing syntax from .() to [], the vector syntax from ~[] to [] and the extension syntax from #fmt() to #fmt[] 2011-08-19 15:16:48 -07:00			`fn main() { null::<int>(); }`