Reverts `latest_client_id` back to 0, as I misunderstood how the client
IDs are assigned and, without further testing and debugging, I can't
say if this was a bug or a valid default value.
Similarly, a `latest_client_id` of -1 is no longer raising an error.
Fixes#39548.
(cherry picked from commit 786f4ada35)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
`latest_client_id` now defaults to `-1` (invalid ID) instead of `0`.
Also fix typo in notification `gdscrip_client/changeWorkspace`,
and fix argument names in method binds.
Fixes#39375.
(cherry picked from commit e34f33711b)
Depending on the conditional statements of the 'for' and 'while' loops,
their body may not even execute once. For example:
func a():
var arr = []
for i in arr:
return i
# can be reached, but analysis says cannot
return -1
func b():
var should_loop = false
while should_loop:
return 1
# can be reached, but analysis says cannot
return 0
The parser will complain that the statements after the comment cannot
be reached, but it is clearly possible for our scenario. This is
because the parser falsely assumes that the loop body will always
execute at least once.
Fix the code to remove this assumption for both of those loops.
(cherry picked from commit 7b1423a61e)
A class can't have multiple signals with the same name, but previously users
would not be alerted to a conflict while editing the script where it occurred.
Now a helpful error will appear in the editor during script parsing.
(cherry picked from commit 9e44739324)
Now the stack saved in a `GDScriptFunctionState` is cleared as soon as the `yield()` operation is known not to be resumed because either the script, the instance or both are deleted.
This clears problems like leaked objects by eliminating cases of circular references between `GDScriptFunctionState`s preventing them and the objects they refer to in their saved stacks from being released. As an example, this makes using `SceneTreeTimer` safer.
Furthermore, with this change it's now possible to print early warnings about `yield()`s to released script/instances, as now we know they won't be successfully resumed as the condition for that happens. However, this PR doesn't add such messages, to keep the observed behavior the same for the time being.
Also, now a backup of the function name in `GDScriptFunctionState` is used, since the script may not be valid by the time the function name is needed for the resume-after-yield error messages.
Calling _reduce_node_type from GDScriptParser::_parse_block for assert
was using a current class with a scope that didn't include all
functions. Now calling in GDScriptParser::_check_block_types uses the
right class type. We also now check the assert node message. The assert
line was added to the set_errors associated with assert, since before
the error would be reported on the next line
(cherry picked from commit bd081df519)
Now calling _reduce_node_type with debugging enabled to determine
if assert line is safe. Part of doing this required the assert line
to be stored away. Now the AssertNode line is being correctly set.
Newlines are now marked safe always
(cherry picked from commit 8dc8833782)
