Don't allow weaker return type in overriden method

[KoBeWi]

This code

class Parent:
	func override_me() -> bool:
		return true

class Child extends Parent:
	func override_me():
		pass

should result in an error, but it didn't.

EDIT:
This breaks methods that return Variant, I'll try to fix it xd

EDIT2:
Fixed and added more tests.

EDIT3:
I added another case for void, but it's rather questionable now 😬

• Bugsquad edit: Fixes GDScript overriden functions can override return type #90694.

[dalexeev]

• See Support covariant return types for overriding functions godot-proposals#7450, the return type shouldn't be less specific, as that violates the Liskov substitution principle. But can be more specific (covariance).

We should also remember about overriding native virtual functions. In this case we should make an exception and allow not specifying the return type (which is treated as Variant by default), for compatibility and convenience of users of untyped GDScript. However, an explicit less specific return type should not be allowed, in my opinion.

[KoBeWi]

In this case we should make an exception and allow not specifying the return type (which is treated as Variant by default), for compatibility and convenience of users of untyped GDScript.

This is already handled by the latest changes.

But can be more specific (covariance).

Yeah, but this is bugfix PR, so more specific type can be implemented later.

[YuriSizov]

@dalexeev How does it look now in your opinion? Probably too risky for 4.2 (regressions in GDScript are known), but would appreciate an approval if this is otherwise good.

@KoBeWi Needs a rebase at some point though 🙃

[KoBeWi]

In this case we should make an exception and allow not specifying the return type (which is treated as Variant by default), for compatibility and convenience of users of untyped GDScript.

This is already handled by the latest changes.

Actually I misunderstood, you are describing the example I specifically showed as undesired. If this needs to be allowed, it should result in a warning at least.

[vnen]

I see two conflicting problems:

1. GDScript should still be dynamically typed, so it shouldn't be forcing users to add types anywhere.
2. There are optimizations based on type information, skipping runtime validation. If some script breaks this contract it may lead to crashes.

Not entirely sure right now how to deal with this conflict.

One potential solution is to treat the overridden method as if it has the same type as the original one if not specified. It may give some type errors even if the user isn't using types, but those would be technically correct. Although it would be tricky to inform the user about the inherited return type.

I believe erroring like this would be annoying for someone who prefers to no use static types. If they inherit from an addon which does use types, they will get these errors, when types are supposed to be optional.

[KoBeWi]

Hence this could be a warning.
I opened this PR because a couple of times I forgot that a method I'm overriding is supposed to return something and it led to non-obvious bugs.