Adds two new GDExtension interface methods:
- `editor_help_load_xml_from_utf8_chars`
- `editor_help_load_xml_from_utf8_chars_and_len`
Both of these methods parse the XML passed into an extra documentation
container which, when needed, is merged into the main doc container.
Co-Authored-By: Rémi Verschelde <rverschelde@gmail.com>
Previously, before loading an extension, the editor just tried to
retrieve the extension by path to test if it's been loaded already.
While this is handled gracefully, it ignored an error thrown inside
`GDExtensionManager::get_extension()`, that would essentially still
report a not yet loaded extension to the engine's log:
```
ERROR: Condition "!E" is true. Returning: Ref<GDExtension>()
at: GDExtensionManager::get_extension (core\extension\gdextension_manager.cpp:165)
```
This change actively checks whether the extension path is known and only
then proceeds to actually return the already loaded extension or loads
and returns the new one otherwise.
So far, an indirection via String was necessary, causing at least 2 allocations and copies (String; String inside StringName).
Since StringNames often refer to string literals, this allows them to be directly constructed from C strings.
There are two formats: Latin-1 and UTF-8.
The Latin-1 constructor also provides the `p_is_static` flag: when the source has static storage duration, no copy/allocation will be needed.
However, the extension developer needs to uphold this lifetime guarantee.
This adds two functions to `GDExtensionClassCreationInfo` that allow for developers to supply a generic virtual call function along with user data to be sent to that call.
If `get_virutal_call_data_func` is not null, extensions call this function to get user data to pass to a supplied `call_virtual_with_data_func`. Both must be provided is one is provided.
If `get_virtual_call_data_func` is null, Godot falls back to the old `get_virtual_func` logic.
Fixes#63275
Co-authored-by: David Snopek <dsnopek@gmail.com>
Previously the `p_reversed` parameter didn't influence the order
in a correct way.
Also script overridden _notification functions were not called in
the correct order.
To fix this some `notification` functions had to add a `p_reversed`
parameter.
This made it necessary to adjust cpp-bindings.
Co-authored-by: David Snopek <dsnopek@gmail.com>
This is done only in the editor and only on Windows, to avoid a file
lock that prevents the original library being updated (e.g. by a
compiler).
When the game runs it will load the original DLL and pick up any
changes, only the editor will stay with the copy (until it is restarted
and create a new copy).
The copy is done in place by prepending a `~` to the original file name,
so dependencies that are loaded with a relative file path still work.
When the library is unloaded the copy file is deleted. The copy is also
marked as hidden to not show up in explorer.
All GDExtension function pointer types are versioned using a `@since` attribute, denoting the Godot minor version in
which they were introduced. This allows bindings to query if a feature is available for a target API version, or provide
a polyfill/fallback for it. It also serves as documentation for humans giving a feeling about recency of features.
- Ensure that multiple changes to one method cannot hide each other in the CI.
- Check virtual methods for changes.
- Compare the detailed changes to a method.
- Compare enums.
- Fix comparing global enums.
- Use `vformat` to build error messages.
This commit introduce separate types (e.g. GDNativeStringPtr vs GDNativeUninitializedStringPtr)
depending on if the pointed data is already initialized (C++ style where constructor is alway
called when create a variable even if it is to be passed as return value) or not (C style).
On top of that, small changes has been made to `GDNativeInterface` so that it methods are
consistent on using uninitialized return value.
This adds a way to ensure that methods that were modified in the Godot API will continue working in older builds of GDExtension even if the new signature is different.
```C++
// New version (changed)
ClassDB::bind_method(D_METHOD("add_sphere","radius","position"),&MyShapes::add_sphere);
// Compatibility version (still available to extensions).
ClassDB::bind_compatibility_method(D_METHOD("add_sphere","radius"),&MyShapes::_compat_add_sphere);
```
**Q**: If I add an extra argument and provide a default value (hence can still be called the same), do I still have to provide the compatibility version?
**A**: Yes, you must still provide a compatibility method. Most language bindings use the raw method pointer to do the call and process the default parameters in the binding language, hence if the actual method signature changes it will no longer work.
**Q**: If I removed a method, can I still bind a compatibility version even though the main method no longer exists?
**A**: Yes, for methods that were removed or renamed, compatibility versions can still be provided.
**Q**: Would it be possible to automate checking that methods were removed by mistake?
**A**: Yes, as part of a future PR, the idea is to add a a command line option to Godot that can be run like : `$ godot --test-api-compatibility older_api_dump.json`, which will also be integrated to the CI runs.
* This should optimize GDScript function calling _enormously_.
* It also should simplify the GDScript VM considerably.
NOTE: GDExtension calling performance has most likely been affected until going via ptrcall is fixed.
