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)
Besides the regular option to export GDScript as binary tokens, this
also includes a compression option on top of it. The binary format
needs to encode some information which generally makes it bigger than
the source text. This option reduces that difference by using Zstandard
compression on the buffer.
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.
Using 2.2.7.dev115+g0eb441d6.
Had to add `cancelled` to the ignore list, as it's a Wayland signal which
we're handling in our code, so we don't want codespell to fix that "typo".
Also includes the typo fix from #87927.
Co-authored-by: Divyanshu Shekhar <61140213+divshekhar@users.noreply.github.com>
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.
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.
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.