Misleading error for abstract method return type

[straight-shoota]

This is extracted from #9454.

Since the changes in 0.35.0 to the return type of IO#write, lot's of errors like this pop up:

In /usr/lib/crystal/io/hexdump.cr:35:28

 35 | def write(buf : Bytes) : Int64
                               ^
Error: method must return Int64 but it is returning (Int64 | Nil)

The problem is that the indicated location is not where the error is. The method IO::Hexdump#write just happens to call #write on the wrapped io. And when there's an IO subtype where #write doesn't have a type restriction, that type causes an error here.
But instead, the error should be reported at the original location where the type restriction is missing.

Isolated example:

abstract class Foo
  abstract def write : Int64
end
 
class Bar < Foo
  def write : Int64 # Error: method must return Int64 but it is returning Nil
    Baz.new.write
  end
end
 
class Baz < Foo
  def write # The error should be reported here!
    nil
  end
end
 
Bar.new.write

Adding Int64 type restriction to Baz#write fixes the issue. Then the compiler error correctly points to Baz#write as the offender.

[asterite]

Just a note that the error has nothing to do with subclasses. Here's the smallest snippet that reproduces this:

abstract class Foo
  abstract def foo : Int32
end

class Bar < Foo
  def foo : Int32
    false
  end
end

Bar.new.foo

The bug is that the abstract def checking produces a warning, but the warning is only shown on the codegen phase (why???). But before reaching that the semantic error already triggers where the return type doesn't match the type of the body.

The solution is to report the warning as soon as it is detected, as it was in the past, before warnings were refactored and moved to the codegen phase. Thank you.

[straight-shoota]

This snippet reproduces the faulty compiler behaviour. But from the user perspective it doesn't matter because it still points you to the location with an appropriate error message.

[asterite]

There's something that's not clear here that I just found out: warnings are not shown if there are compiler errors. In my opinion that's plain wrong.

[asterite]

Oh, well, I guess the first snippet is the one that makes sense. But to fix it, if warnings were reported in addition to errors you would immediately know what the problem is. I have a fix.

But then, I also think "abstract method" warnings should be errors... except that the logic to implement that is very hard so we might not be able to do that before 1.0.