Within a match statement, it is now possible to add guards in each
branch:
var a = 0
match a:
0 when false: print("does not run")
0 when true: print("but this does")
This allows more complex logic for deciding which branch to take.
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 applies our existing style guide, and adds a new rule to that style
guide for modular components such as platform ports and modules:
Includes from the platform port or module ("local" includes) should be listed
first in their own block using relative paths, before Godot's "core" includes
which use "absolute" (project folder relative) paths, and finally thirdparty
includes.
Includes in `#ifdef`s come after their relevant section, i.e. the overall
structure is:
- Local includes
* Conditional local includes
- Core includes
* Conditional core includes
- Thirdparty includes
* Conditional thirdparty includes
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.
