If the type of a variable is a built-in Variant type, then it will
automatically be assigned a default value based on the type. This means
that the explicit initialization may be unnecessary. Thus this commit
removes the warning in such case.
This also changes the meaning of the unassigned warning to happen when
the variable is used before being assigned, not when it has zero
assignments.
If the left value type is known to be String, assume the format operator
(`%`) will return a string, since it works with any type in the right
hand side. This is also used by type inference even if the right hand
type is unknown at compile time.
Not defaulting to the native type rationale:
Defaulting to the native type is less than useful, as:
* There are very few native types that are extensible and have static methods.
* Defaulting to the native type does not account for a method being script-defined.
While the "real fix" would be to carefully track the source of the method, the get_function_signature method is already complicated enough.
This will at least ensure the resulting code should always be valid.
Not triggering on self-calls rationale:
Found in PR comment https://github.com/godotengine/godot/pull/85918#issuecomment-1935864459
```
static func example():
pass
func example2():
example() # self-call on static function
```
Disabling this warning on self-calls is:
* Consistent with other languages
* Important for anonymous classes (where the output code is unusable)
Co-authored-by: K. S. Ernest (iFire) Lee <fire@users.noreply.github.com>
Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
These errors are very common when using an invalid property name
or calling on an object of the wrong type, and the previous message
was a bit cryptic for users.
Co-authored-by: Rémi Verschelde <rverschelde@gmail.com>
Co-authored-by: golfinq <golfinqz@gmail.com>
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.
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.
* Use type hints for `@GlobalScope` enums.
* Use plain `int` for `BitMask<T>`.
* Fix type hints for typed arrays.
* Use `Variant` and `void` type hints.
* Discard unnecessary class prefix.
George Marques
Rémi Verschelde
Jamie Hill-Daniel
Danil Alexeev
20kdc
Yuri Sizov
HolonProduction
Muller-Castro
Jovan Gerodetti
Thaddeus Crews
Jordyfel
Lunarisnia
A Thousand Ships
Chia-Hsiang Cheng
ocean (they/them)
ryanabx
jpcerrone
rune-scape
Rémi Verschelde
Yuri Sizov
Dmitrii Maganov