Unfortunately it appears the virtual function checks in #77324 are not
trustworthy at runtime, because objects can have scripts attached, but
this information is not always available at compile-time. These checks
need to be removed.
The rest of the PR is still useful, making all method flags available to
the analyzer, so a full revert isn't necessary/desirable.
This reopens#76938, which will need another solution.
This PR does a small refactor of how method flags are handled in the GDScript analyzer.
This way, it adds support for the analyzer to use any of MethodInfo's flags, where previously
it could only use METHOD_FLAG_STATIC and METHOD_FLAG_VARARG.
As a side-effect, this also normalizes behavior between editor and release templates, which fixes#76938.
The tests added also brought a different issue to light, where using `super()` appears to generate a
return variable discarded on calling super's _init(), which doesn't have a return value. This should be
tackled in a different PR, which will have to change the output of this PR's tests.
DO NOT BATCH MERGE WITH #77324, WILL RESULT IN BROKEN CI
Currently, calling super() inside _init() throws a
RETURN_VALUE_DISCARDED warning. The analyzer identifies super() as being a
constructor, which therefore returns an object of the relevant class.
However, super() isn't really a constructor by itself: in this case, it
is _part_ of the constructor, and so doesn't "return" a value.
A test case for this is already in #77324, which contains the warning. I
am duplicating it here, without the warning, and it should conflict with
the other PR.
Which allows editable data associated with a particular class instead of
the instance. Scripts with static variables are kept in memory
indefinitely unless the `@static_unload` annotation is used or the
`static_unload()` method is called on the GDScript.
If the custom function `_static_init()` exists it will be called when
the class is loaded, after the static variables are set.
This PR removes a check for whether a datatype is a meta type when
generating a datatype's to_string() result. This means that error
messages that fail to find the type will now print their class names,
which is much more useful when trying to identify errors.
Add functions to CoreConstant so enums can be properly deduced. Also add
the enums in release builds to make consistent with ClassDB enums and
avoid differences in script compilation between debug and release.
