Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Compiler: correctly check abstract methods #7956
This PR does a few things.
Return types are checked
I think this could be enough (the return type of the implemented abstract method might not be mandatory, just deduce the type from method body and check it against abstract def return type, if it's given - that would be the perfect Crystal way):
abstract class Foo abstract def foo : String end class Bar < Foo def foo "aaa" end end
but I understand, that it's hard to implement - by your comments, you have not method bodies in the time of this check - is it even possible?
I also don't like "Overrides" annotation (I don't like annotations at all, it's not Java) - is it even documented somewhere?
But mainly - thanks for your efforts! Can't wait for comments from others.
I think doing it this without forcing a return type annotation is possible, it's just that the implementation will be a bit messier (I have to inject a fake return type that also carries which abstract def it's related to, so that it can be shown in an error, and we have no AST node for that) and I also prefer an explicit return type annotation to be in the source code for clarity, and eventually an
I think the worse case is this:
abstract class Foo abstract def foo : Nil end class Bar < Foo def foo 1 end end # Huh?? Bar.new.foo # => nil
The compiler will copy the
In that case, yeah, we could force an explicit return type so that it's clearer... but since we'll be doing that for at least that case, I'd like it to be done for every case, which is more uniform and clear.
Because for example
Jul 24, 2019
5 checks passed
I guess this change is fine. But it's a potential source for annoying errors coming up in 0.30.0 when you have a large code base implementing abstract methods. It only shows one error at a time so you'll either need a fix-error-repeat cycle until all are fixed or find a different way to identify all malicious methods.
It's good to see that it can be disabled.
With Crinja it actually showed me that the type restrictions on the abstract methods were wrong (which is getting fixed), but if they had been right, there would have been dozens of implementations that need a return type.
I think we can do it as warnings.
My main issue with warnings is that they are opt-in, meaning that almost nobody will really take a look at them when upgrading. Then when we make the warning an error it will cause the same issue, code will break.
So before making this a warning I'd like warnings to be opt-out.
referenced this pull request
Jul 26, 2019
The thing is that this is going to break quite a lot of code. And it can be difficult to fix when the missing return types are in shard dependencies. This will need fixes and updated versions for each of them. And this takes time. I've created PR's against some shards to fix this, but this is probably pretty common.
This breaking change has just come into the nightly build yesterday and the release is coming up in the next days. That's hardly enough time to properly identify and update breaking code. We should give maintainers more time (until 0.31.0) to do this without their code suddenly breaking.
(At the very least, the