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.
Fixes the issue by adding a mechanism by which the functions that were
previously disappearing can be profiled too. This is optional with
an editor setting, since collecting more information naturally slows the engine
further while profiling.
Fixes#23715, #40251, #29049
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>
This assumes that operators are called usually with the same type of
operands as the first time. So it stores the types of the first run and
if matched it uses an optimized path by calling the validated operator
function directly. Otherwise it uses the regular untyped evaluator.
With this change, if operators do use the same type they run quite
faster. OTOH, if the types mismatch it takes longer to run than they
would with the previous code.
* This implementation adds threads on the side of the client (script debugger).
* Some functions of the debugger are optimized.
* The profile is also now thread safe using atomics.
* The editor can switch between multiple threads when debugging.
This PR adds threaded support for the script language debugger. Every thread has its own thread local data and it will connect to the debugger using multiple thread IDs.
This means that, now, the editor can receive multiple threads entering debug mode at the same time.
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
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.
The hard limit is set at 2048 depth which seems sensible between
legitimate recursive calls while still avoiding a crash because of a
stack overflow in most of the cases.
Note that it is still possible to reach the stack limit and get an
overflow before reaching a call depth. This is intended as a half-way
measure to stop crashing in most cases, since there's no reliable nor
portable way to check the amount of stack memory left.
