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.
Errors originating in C++ files cause unnecessary diffs whenever the engine is updated
(line number changes, etc.) and would cause CI failures due to different formatting
of the file path on Windows (backslashes, worked around here anyway) and when using
SCU builds (`../scu` insert).
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.
Set all the default values for typed variables before actually trying to
initialize them, including `@onready` ones.
This ensures that if validated calls are being used there will be a
value of the correct type, even if the resolution is done out of order
or deferred because of `@onready`.