GDScript 2.0: Editor type-infers closest parent with defined _init instead of the class itself

[Aziroshin]

Godot version

v4.0.beta10.official [d0398f6]

System information

Ubuntu 20.04, Ryzen 2700X, GTX 1070

Issue description

Basic example code:

# Food is only there to demonstrate that it isn't a base class issue,
# but that the buck indeed stops with Fruit due to its defined _init.
class Food:
	var loadable := false

class Fruit extends Food:
	var flying := false

	func _init():
		pass

# Berry is only there to demonstrate that the buck doesn't stop with
# the parent class, but indeed is passed on to Fruit, since we don't
# have an _init defined here.
class Berry extends Fruit:
	var explody := false

# Since neither this class nor Berry have an _init defined, this will
# be inferred as Fruit, not Melon.
class Melon extends Berry:
	var extra_splashy := false
	
# Problem:
# There is an _init defined in Fruit, but not in Melon or Berry, so this
# is inferred by the editor as Fruit instead of Melon.
var melon := Melon.new()

# This works, demonstrating that godot indeed understands this as `Melon`.
print(melon.extra_splashy)

At runtime, melon behaves as expected, but in terms of properties the editor's code completion only offers loadable (from grand grand parent Food) and flying (from grand parent Fruit, which has _init) from the class hierarchy, but not explody (from parent Berry) or extra_splashy (Melon - itself). Every subclass in the hierarchy past Fruit, which is the one with _init, is ignored.

Also, when using VSCode the hover-tooltip shows Fruit as the type of melon, with the same above-described completion behaviour as in Godot's builtin editor.

What I'd expect: That melon is type-inferred as Melon, not Fruit.

Steps to reproduce

The minimal reproduction project contains bug.gd, which has three sets of classes and corresponding examples in _ready. The first set demonstrates how no _init in the parent leads to correct type inference, the second demonstrates the problem using the Fruit example, and the third is a bit superfluous, but shows a parent and subclass who both have _init defined, which works as expected.

A few lines are dedicated for uncommenting for easy experimenting, with comments explaining what to do.

The project can be run in order to observe the runtime behaviour of the Fruit example. It should print: This melon is extra splashy: false, demonstrating how a Melon object which is inferred as Fruit indeed has the extra_splashy property of Melon, despite not showing up in the code completion drop-down.

Minimal reproduction project

subclass_init_infer_bug.zip