We don't seem to expose any API that uses `char16_t` yet, but I added it anyway since we make the type info for it.
I didn't add anything for `wchar_t` because we are not making a type info so maybe we don't have a need for it yet, it could be added in the future.
To prevent breaking compatibility with the C# bindings, we ignore the `char32_t` metadata and still use `System.Int64`.
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.
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>
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>
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.
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 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.
