Using 2.2.7.dev217+g10c2abcf.
Had to add `colour` to the ignore list as we used it as an alias/keyword for the
documentation of color-related APIs.
Also ignore recommendations to change `thirdparty` to either `third-party` or
`third party`, which are correct but we use the former fairly consistently.
It is generally expected that the base class is called before the
inherited clas. This commit implements this behavior for the implicit
ready function (`@onready` annotation) to make it consistent with the
expectations.
When the types are validated at compile time, this type of call runs
faster. It is already used for instance methods, this adds this
optimization to native static methods as well.
The warning message mentions that local constants prefixed with `_` does
not generate the warning. This commit actually implements this warning
suppression.
Currently array and dictionary expressions cannot be spread over
multiple lines in match statements.
Adding mutliline push/pop while parsing the pattern for bracket and
brace enables the ability for these to be multiline. This enables more
complex patterns to be matched without exceeding line limits.
Fixes#90372
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)
This adds back a function available in 3.x: exporting the GDScript
files in a binary form by converting the tokens recognized by the
tokenizer into a data format.
It is enabled by default on export but can be manually disabled. The
format helps with loading times since, the tokens are easily
reconstructed, and with hiding the source code, since recovering it
would require a specialized tool. Code comments are not stored in this
format.
The `--test` command can also include a `--use-binary-tokens` flag
which will run the GDScript tests with the binary format instead of the
regular source code by converting them in-memory before the test runs.
This reverts commit c7f68a27ec.
We still think GDScript files need UIDs to allow safe refactoring,
but we're still debating what form those should take exactly.
So far there seems to be agreement that it shouldn't be done via an
annotation as implemented here, so we're reverting this one for now,
to revisit the feature in a future PR.
This method is registered in a special way so ClassDB doesn't naturally
know about its existence. Here it is hardcoded if any other option fail
to check if it is about the `free()` method and, if so, say it exists
and return a Callable.
This improves the performance of typed calls to engine methods when the
argument types are exact.
Using validated calls delegate more of the work the core instead of
doing argument unpacking in the VM. It also does not need different
instructions for each return type, simplifying the code.
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.
