Restrict refute_send_type to check method call doesn't match with type

[pocke]

This pull request adds a more strict check with refute_send_type.

Problem

I think refute_send_type assertion isn't enough to check the type mismatch.

Currently, refute_send_type checks that the method call raises an error, and the method call is matched with the method_type that is specified as an argument of refute_send_type. But the RBS, which is exposed to the end-users, doesn't affect refute_send_type. So it checks nothing about the RBS, but it checks the implementation.

I think refute_send_type should check the RBS, so the current behavior is not enough as a test assertion.

Solution

Check that the RBS declines the method call.

ref: #586 (comment)

[pocke]

Array#sort's block doesn't accept nil as the returned value actually, so I removed nil.

It is a more strict type, but it can be problematic with <=> method.
For example, Integer#<=> may return a nil when the values are incomparable. So the returned type is Integer?.

rbs/core/integer.rbs

Lines 108 to 115 in 26baa08

	# Comparison---Returns -1, 0, or +1 depending on whether `int` is less than,
	# equal to, or greater than `numeric`.
	#
	# This is the basis for the tests in the Comparable module.
	#
	# `nil` is returned if the two values are incomparable.
	#
	def <=>: (Numeric) -> Integer?

So Array#sort will not become to accept the following code by this change.

[1,2,3].sort { |a, b| a <=> b }

But personally I think Integer is better than Integer? as the returned value of sort's block. Array#sort always raises when the block returns nil.
And we can improves Integer#<=> type, like (Integer) => Integer | (Numeric) -> Integer?. The improvement will resolve the Array#sort's problem.

[soutaro]

This makes sense. 👍

(I made it Integer? because of the return type of <=>.)

[soutaro]

@pocke I'm not totally sure if this is the best way. But, I agree that type checking the calls with respect to RBS makes sense. Thanks!