asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/mono/editor/bindings_generator.cpp

3872 lines
138 KiB
C++
Raw Normal View History

Added mono module
2017-10-02 23:24:00 +02:00
/*************************************************************************/
/* bindings_generator.cpp */
/*************************************************************************/
/* This file is part of: */
/* GODOT ENGINE */
/* https://godotengine.org */
/*************************************************************************/
Update copyright statements to 2022 Happy new year to the wonderful Godot community!
2022-01-03 21:27:34 +01:00
/* Copyright (c) 2007-2022 Juan Linietsky, Ariel Manzur. */
/* Copyright (c) 2014-2022 Godot Engine contributors (cf. AUTHORS.md). */
Added mono module
2017-10-02 23:24:00 +02:00
/* */
/* Permission is hereby granted, free of charge, to any person obtaining */
/* a copy of this software and associated documentation files (the */
/* "Software"), to deal in the Software without restriction, including */
/* without limitation the rights to use, copy, modify, merge, publish, */
/* distribute, sublicense, and/or sell copies of the Software, and to */
/* permit persons to whom the Software is furnished to do so, subject to */
/* the following conditions: */
/* */
/* The above copyright notice and this permission notice shall be */
/* included in all copies or substantial portions of the Software. */
/* */
/* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, */
/* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF */
/* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.*/
/* IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY */
/* CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, */
/* TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE */
/* SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */
/*************************************************************************/
Add missing copyright headers and fix formatting Using `misc/scripts/fix_headers.py` on all Godot files. Some missing header guards were added, and the header inclusion order was fixed in the Bullet module.
2018-01-05 00:50:27 +01:00
Added mono module
2017-10-02 23:24:00 +02:00
#include "bindings_generator.h"
Mono: Don't compare API hashes on release builds API hashes cannot be calculated on release builds, as bindings information is lacking. Therefore, we should not be comparing it with the generated glue hash as they will never match.
2019-09-28 01:07:57 +02:00
#if defined(DEBUG_METHODS_ENABLED) && defined(TOOLS_ENABLED)
Added mono module
2017-10-02 23:24:00 +02:00
Reorganized core/ directory, it was too fatty already -Removed FuncRef, since Callable makes it obsolete -Removed int_types.h as its obsolete in c++11+ -Changed color names code
2020-11-07 23:33:38 +01:00
#include "core/config/engine.h"
#include "core/core_constants.h"
Make core/ includes absolute, remove subfolders from include path This allows more consistency in the manner we include core headers, where previously there would be a mix of absolute, relative and include path-dependent includes.
2018-09-11 18:13:45 +02:00
#include "core/io/compression.h"
Core: Move DirAccess and FileAccess to `core/io` File handling APIs are typically considered part of I/O, and we did have most `FileAccess` implementations in `core/io` already.
2021-06-11 14:51:48 +02:00
#include "core/io/dir_access.h"
#include "core/io/file_access.h"
Make core/ includes absolute, remove subfolders from include path This allows more consistency in the manner we include core headers, where previously there would be a mix of absolute, relative and include path-dependent includes.
2018-09-11 18:13:45 +02:00
#include "core/os/os.h"
Reorganized core/ directory, it was too fatty already -Removed FuncRef, since Callable makes it obsolete -Removed int_types.h as its obsolete in c++11+ -Changed color names code
2020-11-07 23:33:38 +01:00
#include "core/string/ucaps.h"
Make glue generation shutdown more graceful
2021-02-22 11:06:33 +01:00
#include "main/main.h"
Added mono module
2017-10-02 23:24:00 +02:00
#include "../godotsharp_defs.h"
#include "../utils/path_utils.h"
#include "../utils/string_utils.h"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
StringBuilder &operator<<(StringBuilder &r_sb, const String &p_string) {
r_sb.append(p_string);
return r_sb;
}
StringBuilder &operator<<(StringBuilder &r_sb, const char *p_cstring) {
r_sb.append(p_cstring);
return r_sb;
}
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
#define CS_INDENT " " // 4 whitespaces
Added mono module
2017-10-02 23:24:00 +02:00
#define INDENT1 CS_INDENT
#define INDENT2 INDENT1 INDENT1
#define INDENT3 INDENT2 INDENT1
#define INDENT4 INDENT3 INDENT1
#define INDENT5 INDENT4 INDENT1
#define MEMBER_BEGIN "\n" INDENT2
#define OPEN_BLOCK "{\n"
#define CLOSE_BLOCK "}\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define OPEN_BLOCK_L1 INDENT1 OPEN_BLOCK
#define OPEN_BLOCK_L2 INDENT2 OPEN_BLOCK
#define OPEN_BLOCK_L3 INDENT3 OPEN_BLOCK
Added mono module
2017-10-02 23:24:00 +02:00
#define CLOSE_BLOCK_L2 INDENT2 CLOSE_BLOCK
#define CLOSE_BLOCK_L3 INDENT3 CLOSE_BLOCK
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CLOSE_BLOCK_L4 INDENT4 CLOSE_BLOCK
Added mono module
2017-10-02 23:24:00 +02:00
C#: Ensure native handles are freed after switch to .NET Core Finalizers are longer guaranteed to be called on exit now that we switched to .NET Core. This results in native instances leaking. The only solution I can think of so far is to keep a list of all instances alive to dispose when the AssemblyLoadContext.Unloading event is raised.
2021-12-28 23:25:16 +01:00
#define BINDINGS_GLOBAL_SCOPE_CLASS "GD"
#define BINDINGS_NATIVE_NAME_FIELD "NativeName"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CS_PARAM_MEMORYOWN "memoryOwn"
Added mono module
2017-10-02 23:24:00 +02:00
#define CS_PARAM_METHODBIND "method"
#define CS_PARAM_INSTANCE "ptr"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CS_STATIC_METHOD_GETINSTANCE "GetPtr"
Added mono module
2017-10-02 23:24:00 +02:00
#define CS_METHOD_CALL "Call"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CS_PROPERTY_SINGLETON "Singleton"
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
#define CS_METHOD_INVOKE_GODOT_CLASS_METHOD "InvokeGodotClassMethod"
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
#define CS_METHOD_HAS_GODOT_CLASS_METHOD "HasGodotClassMethod"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CS_STATIC_FIELD_NATIVE_CTOR "NativeCtor"
#define CS_STATIC_FIELD_METHOD_BIND_PREFIX "MethodBind"
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
#define CS_STATIC_FIELD_METHOD_NAME_PREFIX "MethodName_"
#define CS_STATIC_FIELD_METHOD_PROXY_NAME_PREFIX "MethodProxyName_"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define CS_STATIC_FIELD_SIGNAL_NAME_PREFIX "SignalName_"
Added mono module
2017-10-02 23:24:00 +02:00
#define ICALL_PREFIX "godot_icall_"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define ICALL_CLASSDB_GET_METHOD "ClassDB_get_method"
#define ICALL_CLASSDB_GET_CONSTRUCTOR "ClassDB_get_constructor"
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
#define C_LOCAL_RET "ret"
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
#define C_LOCAL_VARARG_RET "vararg_ret"
Added mono module
2017-10-02 23:24:00 +02:00
#define C_LOCAL_PTRCALL_ARGS "call_args"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define C_CLASS_NATIVE_FUNCS "NativeFuncs"
#define C_NS_MONOUTILS "InteropUtils"
#define C_METHOD_UNMANAGED_GET_MANAGED C_NS_MONOUTILS ".UnmanagedGetManaged"
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
#define C_METHOD_ENGINE_GET_SINGLETON C_NS_MONOUTILS ".EngineGetSingleton"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define C_NS_MONOMARSHAL "Marshaling"
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
#define C_METHOD_MANAGED_TO_VARIANT C_NS_MONOMARSHAL ".ConvertManagedObjectToVariant"
#define C_METHOD_MANAGED_FROM_VARIANT C_NS_MONOMARSHAL ".ConvertVariantToManagedObject"
#define C_METHOD_MONOSTR_TO_GODOT C_NS_MONOMARSHAL ".ConvertStringToNative"
#define C_METHOD_MONOSTR_FROM_GODOT C_NS_MONOMARSHAL ".ConvertStringToManaged"
#define C_METHOD_MONOARRAY_TO(m_type) C_NS_MONOMARSHAL ".ConvertSystemArrayToNative" #m_type
#define C_METHOD_MONOARRAY_FROM(m_type) C_NS_MONOMARSHAL ".ConvertNative" #m_type "ToSystemArray"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define C_METHOD_MANAGED_TO_CALLABLE C_NS_MONOMARSHAL ".ConvertCallableToNative"
#define C_METHOD_MANAGED_FROM_CALLABLE C_NS_MONOMARSHAL ".ConvertCallableToManaged"
#define C_METHOD_MANAGED_TO_SIGNAL C_NS_MONOMARSHAL ".ConvertSignalToNative"
#define C_METHOD_MANAGED_FROM_SIGNAL C_NS_MONOMARSHAL ".ConvertSignalToManaged"
Mono: Better versioning and gracefully unloading of Godot API assemblies
2018-02-22 13:13:51 +01:00
Ignore PhysicsServer3DExtension class in C# PhysicsServer3DExtension inherits from PhysicsServer3D which is a singleton class, since singleton classes are generated as static in C# it would generate invalid C# so for now we'll be ignoring PhysicsServer3DExtension.
2022-03-18 17:28:48 +01:00
// Types that will be ignored by the generator and won't be available in C#.
const Vector<String> ignored_types = { "PhysicsServer3DExtension" };
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
void BindingsGenerator::TypeInterface::postsetup_enum_type(BindingsGenerator::TypeInterface &r_enum_itype) {
// C interface for enums is the same as that of 'uint32_t'. Remember to apply
// any of the changes done here to the 'uint32_t' type interface as well.
r_enum_itype.cs_type = r_enum_itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
r_enum_itype.cs_in_expr = "(int)%0";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_enum_itype.cs_out = "%5return (%2)%0(%1);";
{
// The expected types for parameters and return value in ptrcall are 'int64_t' or 'uint64_t'.
r_enum_itype.c_in = "%5%0 %1_in = %1;\n";
r_enum_itype.c_out = "%5return (%0)%1;\n";
r_enum_itype.c_type = "long";
r_enum_itype.c_arg_in = "&%s_in";
}
r_enum_itype.c_type_in = "int";
r_enum_itype.c_type_out = r_enum_itype.c_type_in;
r_enum_itype.class_doc = &EditorHelp::get_doc_data()->class_list[r_enum_itype.proxy_name];
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
static String fix_doc_description(const String &p_bbcode) {
// This seems to be the correct way to do this. It's the same EditorHelp does.
return p_bbcode.dedent()
.replace("\t", "")
.replace("\r", "")
.strip_edges();
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
static String snake_to_pascal_case(const String &p_identifier, bool p_input_is_upper = false) {
Added mono module
2017-10-02 23:24:00 +02:00
String ret;
Vector<String> parts = p_identifier.split("_", true);
for (int i = 0; i < parts.size(); i++) {
String part = parts[i];
if (part.length()) {
part[0] = _find_upper(part[0]);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (p_input_is_upper) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
for (int j = 1; j < part.length(); j++) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
part[j] = _find_lower(part[j]);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
ret += part;
} else {
if (i == 0 || i == (parts.size() - 1)) {
// Preserve underscores at the beginning and end
ret += "_";
} else {
// Preserve contiguous underscores
if (parts[i - 1].length()) {
ret += "__";
} else {
ret += "_";
}
}
}
}
return ret;
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
static String snake_to_camel_case(const String &p_identifier, bool p_input_is_upper = false) {
Added mono module
2017-10-02 23:24:00 +02:00
String ret;
Vector<String> parts = p_identifier.split("_", true);
for (int i = 0; i < parts.size(); i++) {
String part = parts[i];
if (part.length()) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (i != 0) {
Added mono module
2017-10-02 23:24:00 +02:00
part[0] = _find_upper(part[0]);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
if (p_input_is_upper) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
for (int j = i != 0 ? 1 : 0; j < part.length(); j++) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
part[j] = _find_lower(part[j]);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
ret += part;
} else {
if (i == 0 || i == (parts.size() - 1)) {
// Preserve underscores at the beginning and end
ret += "_";
} else {
// Preserve contiguous underscores
if (parts[i - 1].length()) {
ret += "__";
} else {
ret += "_";
}
}
}
}
return ret;
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String BindingsGenerator::bbcode_to_xml(const String &p_bbcode, const TypeInterface *p_itype) {
// Based on the version in EditorHelp
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (p_bbcode.is_empty()) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
return String();
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
Refactor DocData into core and editor (DocTools) parts
2020-11-29 04:42:06 +01:00
DocTools *doc = EditorHelp::get_doc_data();
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String bbcode = p_bbcode;
StringBuilder xml_output;
xml_output.append("<para>");
List<String> tag_stack;
bool code_tag = false;
int pos = 0;
while (pos < bbcode.length()) {
int brk_pos = bbcode.find("[", pos);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (brk_pos < 0) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
brk_pos = bbcode.length();
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (brk_pos > pos) {
String text = bbcode.substr(pos, brk_pos - pos);
if (code_tag || tag_stack.size() > 0) {
xml_output.append(text.xml_escape());
} else {
Vector<String> lines = text.split("\n");
for (int i = 0; i < lines.size(); i++) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i != 0) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("<para>");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append(lines[i].xml_escape());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i != lines.size() - 1) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("</para>\n");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
}
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (brk_pos == bbcode.length()) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
break; // nothing else to add
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
int brk_end = bbcode.find("]", brk_pos + 1);
if (brk_end == -1) {
String text = bbcode.substr(brk_pos, bbcode.length() - brk_pos);
if (code_tag || tag_stack.size() > 0) {
xml_output.append(text.xml_escape());
} else {
Vector<String> lines = text.split("\n");
for (int i = 0; i < lines.size(); i++) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i != 0) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("<para>");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append(lines[i].xml_escape());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i != lines.size() - 1) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("</para>\n");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
}
break;
}
String tag = bbcode.substr(brk_pos + 1, brk_end - brk_pos - 1);
if (tag.begins_with("/")) {
bool tag_ok = tag_stack.size() && tag_stack.front()->get() == tag.substr(1, tag.length());
if (!tag_ok) {
xml_output.append("[");
pos = brk_pos + 1;
continue;
}
tag_stack.pop_front();
pos = brk_end + 1;
code_tag = false;
if (tag == "/url") {
xml_output.append("</a>");
} else if (tag == "/code") {
xml_output.append("</c>");
} else if (tag == "/codeblock") {
xml_output.append("</code>");
}
} else if (code_tag) {
xml_output.append("[");
pos = brk_pos + 1;
Add theme_item support to C# documentation generator
2022-02-14 16:24:35 +01:00
} else if (tag.begins_with("method ") || tag.begins_with("member ") || tag.begins_with("signal ") || tag.begins_with("enum ") || tag.begins_with("constant ") || tag.begins_with("theme_item ")) {
Support signals in C# documentation
2022-02-09 19:01:18 +01:00
const int tag_end = tag.find(" ");
const String link_tag = tag.substr(0, tag_end);
const String link_target = tag.substr(tag_end + 1, tag.length()).lstrip(" ");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
const Vector<String> link_target_parts = link_target.split(".");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (link_target_parts.size() <= 0 || link_target_parts.size() > 2) {
Remove duplicate ERR_PRINT macro.
2019-11-06 17:03:04 +01:00
ERR_PRINT("Invalid reference format: '" + tag + "'.");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("<c>");
xml_output.append(tag);
xml_output.append("</c>");
pos = brk_end + 1;
continue;
}
const TypeInterface *target_itype;
StringName target_cname;
if (link_target_parts.size() == 2) {
target_itype = _get_type_or_null(TypeReference(link_target_parts[0]));
if (!target_itype) {
target_itype = _get_type_or_null(TypeReference("_" + link_target_parts[0]));
}
target_cname = link_target_parts[1];
} else {
target_itype = p_itype;
target_cname = link_target_parts[0];
}
if (link_tag == "method") {
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_method(xml_output, target_itype, target_cname, link_target, link_target_parts);
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
} else if (link_tag == "member") {
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_member(xml_output, target_itype, target_cname, link_target, link_target_parts);
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
} else if (link_tag == "signal") {
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_signal(xml_output, target_itype, target_cname, link_target, link_target_parts);
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
} else if (link_tag == "enum") {
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_enum(xml_output, target_itype, target_cname, link_target, link_target_parts);
Fix constant tag documentation in C# bindings generator
2021-08-04 21:17:16 +02:00
} else if (link_tag == "constant") {
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_constant(xml_output, target_itype, target_cname, link_target, link_target_parts);
Add theme_item support to C# documentation generator
2022-02-14 16:24:35 +01:00
} else if (link_tag == "theme_item") {
// We do not declare theme_items in any way in C#, so there is nothing to reference
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
_append_xml_undeclared(xml_output, link_target);
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
pos = brk_end + 1;
} else if (doc->class_list.has(tag)) {
if (tag == "Array" || tag == "Dictionary") {
xml_output.append("<see cref=\"" BINDINGS_NAMESPACE_COLLECTIONS ".");
xml_output.append(tag);
xml_output.append("\"/>");
} else if (tag == "bool" || tag == "int") {
xml_output.append("<see cref=\"");
xml_output.append(tag);
xml_output.append("\"/>");
} else if (tag == "float") {
xml_output.append("<see cref=\""
#ifdef REAL_T_IS_DOUBLE
"double"
#else
"float"
#endif
"\"/>");
} else if (tag == "Variant") {
// We use System.Object for Variant, so there is no Variant type in C#
xml_output.append("<c>Variant</c>");
} else if (tag == "String") {
xml_output.append("<see cref=\"string\"/>");
} else if (tag == "Nil") {
xml_output.append("<see langword=\"null\"/>");
} else if (tag.begins_with("@")) {
EditorHelp, makerst: Improve enum ref resolving and constant ref support Enum reference resolving will now search in the @GlobalScope if no class is specified and the enum cannot be resolved in the current class. Added support for constant references in EditorHelp, e.g.: [constant KEY_ENTER] or [constant Control.FOCUS_CLICK]. It supports enum constants (the enum name must not be included).
2019-03-27 20:01:16 +01:00
// @GlobalScope, @GDScript, etc
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("<c>");
xml_output.append(tag);
xml_output.append("</c>");
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
} else if (tag == "PackedByteArray") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"byte\"/>[]");
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
} else if (tag == "PackedInt32Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"int\"/>[]");
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
} else if (tag == "PackedInt64Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"long\"/>[]");
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
} else if (tag == "PackedFloat32Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"float\"/>[]");
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
} else if (tag == "PackedFloat64Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"double\"/>[]");
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
} else if (tag == "PackedStringArray") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"string\"/>[]");
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
} else if (tag == "PackedVector2Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".Vector2\"/>[]");
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
} else if (tag == "PackedVector3Array") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".Vector3\"/>[]");
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
} else if (tag == "PackedColorArray") {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".Color\"/>[]");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
} else {
const TypeInterface *target_itype = _get_type_or_null(TypeReference(tag));
if (!target_itype) {
target_itype = _get_type_or_null(TypeReference("_" + tag));
}
if (target_itype) {
xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
xml_output.append(target_itype->proxy_name);
xml_output.append("\"/>");
} else {
Remove duplicate ERR_PRINT macro.
2019-11-06 17:03:04 +01:00
ERR_PRINT("Cannot resolve type reference in documentation: '" + tag + "'.");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
xml_output.append("<c>");
xml_output.append(tag);
xml_output.append("</c>");
}
}
pos = brk_end + 1;
} else if (tag == "b") {
// bold is not supported in xml comments
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "i") {
// italics is not supported in xml comments
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "code") {
xml_output.append("<c>");
code_tag = true;
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "codeblock") {
xml_output.append("<code>");
code_tag = true;
pos = brk_end + 1;
tag_stack.push_front(tag);
Improve shortcut formatting in docs
2020-03-10 11:41:36 +01:00
} else if (tag == "kbd") {
// keyboard combinations are not supported in xml comments
pos = brk_end + 1;
tag_stack.push_front(tag);
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
} else if (tag == "center") {
Improve shortcut formatting in docs
2020-03-10 11:41:36 +01:00
// center alignment is not supported in xml comments
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "br") {
xml_output.append("\n"); // FIXME: Should use <para> instead. Luckily this tag isn't used for now.
pos = brk_end + 1;
} else if (tag == "u") {
// underline is not supported in xml comments
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "s") {
// strikethrough is not supported in xml comments
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag == "url") {
int end = bbcode.find("[", brk_end);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (end == -1) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
end = bbcode.length();
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String url = bbcode.substr(brk_end + 1, end - brk_end - 1);
xml_output.append("<a href=\"");
xml_output.append(url);
xml_output.append("\">");
xml_output.append(url);
pos = brk_end + 1;
tag_stack.push_front(tag);
} else if (tag.begins_with("url=")) {
String url = tag.substr(4, tag.length());
xml_output.append("<a href=\"");
xml_output.append(url);
xml_output.append("\">");
pos = brk_end + 1;
tag_stack.push_front("url");
} else if (tag == "img") {
int end = bbcode.find("[", brk_end);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (end == -1) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
end = bbcode.length();
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String image = bbcode.substr(brk_end + 1, end - brk_end - 1);
// Not supported. Just append the bbcode.
xml_output.append("[img]");
xml_output.append(image);
xml_output.append("[/img]");
pos = end;
tag_stack.push_front(tag);
} else if (tag.begins_with("color=")) {
// Not supported.
pos = brk_end + 1;
tag_stack.push_front("color");
} else if (tag.begins_with("font=")) {
// Not supported.
pos = brk_end + 1;
tag_stack.push_front("font");
} else {
xml_output.append("["); // ignore
pos = brk_pos + 1;
}
}
xml_output.append("</para>");
return xml_output.as_string();
}
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
void BindingsGenerator::_append_xml_method(StringBuilder &p_xml_output, const TypeInterface *p_target_itype, const StringName &p_target_cname, const String &p_link_target, const Vector<String> &p_link_target_parts) {
if (p_link_target_parts[0] == name_cache.type_at_GlobalScope) {
if (OS::get_singleton()->is_stdout_verbose()) {
OS::get_singleton()->print("Cannot resolve @GlobalScope method reference in documentation: %s\n", p_link_target.utf8().get_data());
}
// TODO Map what we can
_append_xml_undeclared(p_xml_output, p_link_target);
} else if (!p_target_itype || !p_target_itype->is_object_type) {
if (OS::get_singleton()->is_stdout_verbose()) {
if (p_target_itype) {
OS::get_singleton()->print("Cannot resolve method reference for non-Godot.Object type in documentation: %s\n", p_link_target.utf8().get_data());
} else {
OS::get_singleton()->print("Cannot resolve type from method reference in documentation: %s\n", p_link_target.utf8().get_data());
}
}
// TODO Map what we can
_append_xml_undeclared(p_xml_output, p_link_target);
} else {
if (p_target_cname == "_init") {
// The _init method is not declared in C#, reference the constructor instead
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append("()\"/>");
} else {
const MethodInterface *target_imethod = p_target_itype->find_method_by_name(p_target_cname);
if (target_imethod) {
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(target_imethod->proxy_name);
p_xml_output.append("\"/>");
} else {
ERR_PRINT("Cannot resolve method reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
}
}
void BindingsGenerator::_append_xml_member(StringBuilder &p_xml_output, const TypeInterface *p_target_itype, const StringName &p_target_cname, const String &p_link_target, const Vector<String> &p_link_target_parts) {
if (p_link_target.find("/") >= 0) {
// Properties with '/' (slash) in the name are not declared in C#, so there is nothing to reference.
_append_xml_undeclared(p_xml_output, p_link_target);
} else if (!p_target_itype || !p_target_itype->is_object_type) {
if (OS::get_singleton()->is_stdout_verbose()) {
if (p_target_itype) {
OS::get_singleton()->print("Cannot resolve member reference for non-Godot.Object type in documentation: %s\n", p_link_target.utf8().get_data());
} else {
OS::get_singleton()->print("Cannot resolve type from member reference in documentation: %s\n", p_link_target.utf8().get_data());
}
}
// TODO Map what we can
_append_xml_undeclared(p_xml_output, p_link_target);
} else {
const TypeInterface *current_itype = p_target_itype;
const PropertyInterface *target_iprop = nullptr;
while (target_iprop == nullptr && current_itype != nullptr) {
target_iprop = current_itype->find_property_by_name(p_target_cname);
if (target_iprop == nullptr) {
current_itype = _get_type_or_null(TypeReference(current_itype->base_name));
}
}
if (target_iprop) {
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(current_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(target_iprop->proxy_name);
p_xml_output.append("\"/>");
} else {
ERR_PRINT("Cannot resolve member reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
}
void BindingsGenerator::_append_xml_signal(StringBuilder &p_xml_output, const TypeInterface *p_target_itype, const StringName &p_target_cname, const String &p_link_target, const Vector<String> &p_link_target_parts) {
if (!p_target_itype || !p_target_itype->is_object_type) {
if (OS::get_singleton()->is_stdout_verbose()) {
if (p_target_itype) {
OS::get_singleton()->print("Cannot resolve signal reference for non-Godot.Object type in documentation: %s\n", p_link_target.utf8().get_data());
} else {
OS::get_singleton()->print("Cannot resolve type from signal reference in documentation: %s\n", p_link_target.utf8().get_data());
}
}
// TODO Map what we can
_append_xml_undeclared(p_xml_output, p_link_target);
} else {
const SignalInterface *target_isignal = p_target_itype->find_signal_by_name(p_target_cname);
if (target_isignal) {
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(target_isignal->proxy_name);
p_xml_output.append("\"/>");
} else {
ERR_PRINT("Cannot resolve signal reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
}
void BindingsGenerator::_append_xml_enum(StringBuilder &p_xml_output, const TypeInterface *p_target_itype, const StringName &p_target_cname, const String &p_link_target, const Vector<String> &p_link_target_parts) {
const StringName search_cname = !p_target_itype ? p_target_cname : StringName(p_target_itype->name + "." + (String)p_target_cname);
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, TypeInterface>::ConstIterator enum_match = enum_types.find(search_cname);
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
if (!enum_match && search_cname != p_target_cname) {
enum_match = enum_types.find(p_target_cname);
}
if (enum_match) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
const TypeInterface &target_enum_itype = enum_match->value;
Refactor `bbcode_to_xml` into multiple specific methods The specific `_append_xml_*` methods implement the logic that generates the proper XML documentation for the given BBCode tag and target and appends it to the output.
2022-03-03 23:35:10 +01:00
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(target_enum_itype.proxy_name); // Includes nesting class if any
p_xml_output.append("\"/>");
} else {
ERR_PRINT("Cannot resolve enum reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
void BindingsGenerator::_append_xml_constant(StringBuilder &p_xml_output, const TypeInterface *p_target_itype, const StringName &p_target_cname, const String &p_link_target, const Vector<String> &p_link_target_parts) {
if (p_link_target_parts[0] == name_cache.type_at_GlobalScope) {
_append_xml_constant_in_global_scope(p_xml_output, p_target_cname, p_link_target);
} else if (!p_target_itype || !p_target_itype->is_object_type) {
// Search in @GlobalScope as a last resort if no class was specified
if (p_link_target_parts.size() == 1) {
_append_xml_constant_in_global_scope(p_xml_output, p_target_cname, p_link_target);
return;
}
if (OS::get_singleton()->is_stdout_verbose()) {
if (p_target_itype) {
OS::get_singleton()->print("Cannot resolve constant reference for non-Godot.Object type in documentation: %s\n", p_link_target.utf8().get_data());
} else {
OS::get_singleton()->print("Cannot resolve type from constant reference in documentation: %s\n", p_link_target.utf8().get_data());
}
}
// TODO Map what we can
_append_xml_undeclared(p_xml_output, p_link_target);
} else {
// Try to find the constant in the current class
const ConstantInterface *target_iconst = find_constant_by_name(p_target_cname, p_target_itype->constants);
if (target_iconst) {
// Found constant in current class
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(target_iconst->proxy_name);
p_xml_output.append("\"/>");
} else {
// Try to find as enum constant in the current class
const EnumInterface *target_ienum = nullptr;
for (const EnumInterface &ienum : p_target_itype->enums) {
target_ienum = &ienum;
target_iconst = find_constant_by_name(p_target_cname, target_ienum->constants);
if (target_iconst) {
break;
}
}
if (target_iconst) {
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(p_target_itype->proxy_name);
p_xml_output.append(".");
p_xml_output.append(target_ienum->cname);
p_xml_output.append(".");
p_xml_output.append(target_iconst->proxy_name);
p_xml_output.append("\"/>");
} else if (p_link_target_parts.size() == 1) {
// Also search in @GlobalScope as a last resort if no class was specified
_append_xml_constant_in_global_scope(p_xml_output, p_target_cname, p_link_target);
} else {
ERR_PRINT("Cannot resolve constant reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
}
}
void BindingsGenerator::_append_xml_constant_in_global_scope(StringBuilder &p_xml_output, const String &p_target_cname, const String &p_link_target) {
// Try to find as a global constant
const ConstantInterface *target_iconst = find_constant_by_name(p_target_cname, global_constants);
if (target_iconst) {
// Found global constant
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE "." BINDINGS_GLOBAL_SCOPE_CLASS ".");
p_xml_output.append(target_iconst->proxy_name);
p_xml_output.append("\"/>");
} else {
// Try to find as global enum constant
const EnumInterface *target_ienum = nullptr;
for (const EnumInterface &ienum : global_enums) {
target_ienum = &ienum;
target_iconst = find_constant_by_name(p_target_cname, target_ienum->constants);
if (target_iconst) {
break;
}
}
if (target_iconst) {
p_xml_output.append("<see cref=\"" BINDINGS_NAMESPACE ".");
p_xml_output.append(target_ienum->cname);
p_xml_output.append(".");
p_xml_output.append(target_iconst->proxy_name);
p_xml_output.append("\"/>");
} else {
ERR_PRINT("Cannot resolve global constant reference in documentation: '" + p_link_target + "'.");
_append_xml_undeclared(p_xml_output, p_link_target);
}
}
}
void BindingsGenerator::_append_xml_undeclared(StringBuilder &p_xml_output, const String &p_link_target) {
p_xml_output.append("<c>");
p_xml_output.append(p_link_target);
p_xml_output.append("</c>");
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
int BindingsGenerator::_determine_enum_prefix(const EnumInterface &p_ienum) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
CRASH_COND(p_ienum.constants.is_empty());
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
const ConstantInterface &front_iconstant = p_ienum.constants.front()->get();
Vector<String> front_parts = front_iconstant.name.split("_", /* p_allow_empty: */ true);
int candidate_len = front_parts.size() - 1;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (candidate_len == 0) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
return 0;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
Use C++ iterators in the Mono module
2021-07-26 21:31:17 +02:00
for (const ConstantInterface &iconstant : p_ienum.constants) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
Vector<String> parts = iconstant.name.split("_", /* p_allow_empty: */ true);
int i;
for (i = 0; i < candidate_len && i < parts.size(); i++) {
if (front_parts[i] != parts[i]) {
// HARDCODED: Some Flag enums have the prefix 'FLAG_' for everything except 'FLAGS_DEFAULT' (same for 'METHOD_FLAG_' and'METHOD_FLAGS_DEFAULT').
bool hardcoded_exc = (i == candidate_len - 1 && ((front_parts[i] == "FLAGS" && parts[i] == "FLAG") || (front_parts[i] == "FLAG" && parts[i] == "FLAGS")));
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (!hardcoded_exc) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
break;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
candidate_len = i;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (candidate_len == 0) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
return 0;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
return candidate_len;
}
void BindingsGenerator::_apply_prefix_to_enum_constants(BindingsGenerator::EnumInterface &p_ienum, int p_prefix_length) {
if (p_prefix_length > 0) {
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (ConstantInterface &iconstant : p_ienum.constants) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
int curr_prefix_length = p_prefix_length;
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
String constant_name = iconstant.name;
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
Vector<String> parts = constant_name.split("_", /* p_allow_empty: */ true);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (parts.size() <= curr_prefix_length) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
Cleanup and move char functions to the `char_utils.h` header.
2022-02-04 09:32:20 +01:00
if (is_digit(parts[curr_prefix_length][0])) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
// The name of enum constants may begin with a numeric digit when strip from the enum prefix,
// so we make the prefix for this constant one word shorter in those cases.
for (curr_prefix_length = curr_prefix_length - 1; curr_prefix_length > 0; curr_prefix_length--) {
Cleanup and move char functions to the `char_utils.h` header.
2022-02-04 09:32:20 +01:00
if (!is_digit(parts[curr_prefix_length][0])) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
break;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
}
}
constant_name = "";
for (int i = curr_prefix_length; i < parts.size(); i++) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i > curr_prefix_length) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
constant_name += "_";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
constant_name += parts[i];
}
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
iconstant.proxy_name = snake_to_pascal_case(constant_name, true);
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
}
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
Error BindingsGenerator::_populate_method_icalls_table(const TypeInterface &p_itype) {
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const MethodInterface &imethod : p_itype.methods) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (imethod.is_virtual) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *return_type = _get_type_or_null(imethod.return_type);
ERR_FAIL_NULL_V(return_type, ERR_BUG); // Return type not found
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
String im_unique_sig = get_ret_unique_sig(return_type) + ",CallMethodBind";
Mono: Fix NodePath and RID bindings
2018-01-25 23:44:37 +01:00
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
if (!imethod.is_static) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
im_unique_sig += ",CallInstance";
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
// Get arguments information
int i = 0;
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const ArgumentInterface &iarg : imethod.arguments) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *arg_type = _get_type_or_null(iarg.type);
ERR_FAIL_NULL_V(arg_type, ERR_BUG); // Argument type not found
Added mono module
2017-10-02 23:24:00 +02:00
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
im_unique_sig += ",";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
im_unique_sig += get_arg_unique_sig(*arg_type);
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
i++;
}
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
// godot_icall_{argc}_{icallcount}
Mono: Fix NodePath and RID bindings
2018-01-25 23:44:37 +01:00
String icall_method = ICALL_PREFIX;
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
icall_method += itos(imethod.arguments.size());
icall_method += "_";
icall_method += itos(method_icalls.size());
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
InternalCall im_icall = InternalCall(p_itype.api_type, icall_method, im_unique_sig);
im_icall.is_vararg = imethod.is_vararg;
im_icall.is_static = imethod.is_static;
im_icall.return_type = imethod.return_type;
for (const List<ArgumentInterface>::Element *F = imethod.arguments.front(); F; F = F->next()) {
im_icall.argument_types.push_back(F->get().type);
}
Added mono module
2017-10-02 23:24:00 +02:00
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
List<InternalCall>::Element *match = method_icalls.find(im_icall);
Added mono module
2017-10-02 23:24:00 +02:00
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (match) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (p_itype.api_type != ClassDB::API_EDITOR) {
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
match->get().editor_only = false;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
method_icalls_map.insert(&imethod, &match->get());
Added mono module
2017-10-02 23:24:00 +02:00
} else {
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
List<InternalCall>::Element *added = method_icalls.push_back(im_icall);
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
method_icalls_map.insert(&imethod, &added->get());
Added mono module
2017-10-02 23:24:00 +02:00
}
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
return OK;
Added mono module
2017-10-02 23:24:00 +02:00
}
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
void BindingsGenerator::_generate_array_extensions(StringBuilder &p_output) {
p_output.append("using System;\n\n");
p_output.append("namespace " BINDINGS_NAMESPACE "\n" OPEN_BLOCK);
// The class where we put the extensions doesn't matter, so just use "GD".
p_output.append(INDENT1 "public static partial class " BINDINGS_GLOBAL_SCOPE_CLASS "\n" INDENT1 "{");
#define ARRAY_IS_EMPTY(m_type) \
p_output.append("\n" INDENT2 "/// <summary>\n"); \
p_output.append(INDENT2 "/// Returns true if this " #m_type " array is empty or doesn't exist.\n"); \
p_output.append(INDENT2 "/// </summary>\n"); \
p_output.append(INDENT2 "/// <param name=\"instance\">The " #m_type " array check.</param>\n"); \
p_output.append(INDENT2 "/// <returns>Whether or not the array is empty.</returns>\n"); \
p_output.append(INDENT2 "public static bool IsEmpty(this " #m_type "[] instance)\n"); \
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(OPEN_BLOCK_L2); \
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
p_output.append(INDENT3 "return instance == null || instance.Length == 0;\n"); \
p_output.append(INDENT2 CLOSE_BLOCK);
#define ARRAY_JOIN(m_type) \
p_output.append("\n" INDENT2 "/// <summary>\n"); \
p_output.append(INDENT2 "/// Converts this " #m_type " array to a string delimited by the given string.\n"); \
p_output.append(INDENT2 "/// </summary>\n"); \
p_output.append(INDENT2 "/// <param name=\"instance\">The " #m_type " array to convert.</param>\n"); \
p_output.append(INDENT2 "/// <param name=\"delimiter\">The delimiter to use between items.</param>\n"); \
p_output.append(INDENT2 "/// <returns>A single string with all items.</returns>\n"); \
p_output.append(INDENT2 "public static string Join(this " #m_type "[] instance, string delimiter = \", \")\n"); \
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(OPEN_BLOCK_L2); \
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
p_output.append(INDENT3 "return String.Join(delimiter, instance);\n"); \
p_output.append(INDENT2 CLOSE_BLOCK);
#define ARRAY_STRINGIFY(m_type) \
p_output.append("\n" INDENT2 "/// <summary>\n"); \
p_output.append(INDENT2 "/// Converts this " #m_type " array to a string with brackets.\n"); \
p_output.append(INDENT2 "/// </summary>\n"); \
p_output.append(INDENT2 "/// <param name=\"instance\">The " #m_type " array to convert.</param>\n"); \
p_output.append(INDENT2 "/// <returns>A single string with all items.</returns>\n"); \
p_output.append(INDENT2 "public static string Stringify(this " #m_type "[] instance)\n"); \
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(OPEN_BLOCK_L2); \
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
p_output.append(INDENT3 "return \"[\" + instance.Join() + \"]\";\n"); \
p_output.append(INDENT2 CLOSE_BLOCK);
#define ARRAY_ALL(m_type) \
ARRAY_IS_EMPTY(m_type) \
ARRAY_JOIN(m_type) \
ARRAY_STRINGIFY(m_type)
ARRAY_ALL(byte);
ARRAY_ALL(int);
ARRAY_ALL(long);
ARRAY_ALL(float);
ARRAY_ALL(double);
ARRAY_ALL(string);
ARRAY_ALL(Color);
ARRAY_ALL(Vector2);
ARRAY_ALL(Vector2i);
ARRAY_ALL(Vector3);
ARRAY_ALL(Vector3i);
Implement Vector4, Vector4i, Projection Implement built-in classes Vector4, Vector4i and Projection. * Two versions of Vector4 (float and integer). * A Projection class, which is a 4x4 matrix specialized in projection types. These types have been requested for a long time, but given they were very corner case they were not added before. Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity. **Q**: Why Projection and not Matrix4? **A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
2022-07-20 01:11:13 +02:00
ARRAY_ALL(Vector4);
ARRAY_ALL(Vector4i);
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
#undef ARRAY_ALL
#undef ARRAY_IS_EMPTY
#undef ARRAY_JOIN
#undef ARRAY_STRINGIFY
p_output.append(INDENT1 CLOSE_BLOCK); // End of GD class.
p_output.append(CLOSE_BLOCK); // End of namespace.
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
void BindingsGenerator::_generate_global_constants(StringBuilder &p_output) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Constants (in partial GD class)
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n#pragma warning disable CS1591 // Disable warning: "
"'Missing XML comment for publicly visible type or member'\n");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("namespace " BINDINGS_NAMESPACE "\n" OPEN_BLOCK);
p_output.append(INDENT1 "public static partial class " BINDINGS_GLOBAL_SCOPE_CLASS "\n" INDENT1 "{");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const ConstantInterface &iconstant : global_constants) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (iconstant.const_doc && iconstant.const_doc->description.size()) {
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
String xml_summary = bbcode_to_xml(fix_doc_description(iconstant.const_doc->description), nullptr);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (summary_lines.size()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(MEMBER_BEGIN "/// <summary>\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
for (int i = 0; i < summary_lines.size(); i++) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// ");
p_output.append(summary_lines[i]);
p_output.append("\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// </summary>");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
p_output.append(MEMBER_BEGIN "public const long ");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(iconstant.proxy_name);
p_output.append(" = ");
p_output.append(itos(iconstant.value));
p_output.append(";");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (!global_constants.is_empty()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT1 CLOSE_BLOCK); // end of GD class
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Enums
Use const references where possible for List range iterators
2021-07-24 15:46:25 +02:00
for (const EnumInterface &ienum : global_enums) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
CRASH_COND(ienum.constants.is_empty());
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
String enum_proxy_name = ienum.cname.operator String();
bool enum_in_static_class = false;
if (enum_proxy_name.find(".") > 0) {
enum_in_static_class = true;
String enum_class_name = enum_proxy_name.get_slicec('.', 0);
enum_proxy_name = enum_proxy_name.get_slicec('.', 1);
CRASH_COND(enum_class_name != "Variant"); // Hard-coded...
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
_log("Declaring global enum '%s' inside static class '%s'\n", enum_proxy_name.utf8().get_data(), enum_class_name.utf8().get_data());
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n" INDENT1 "public static partial class ");
p_output.append(enum_class_name);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("\n" OPEN_BLOCK_L1);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Add C# support for bitfield enums (flags)
2022-06-24 20:25:30 +02:00
if (ienum.is_flags) {
p_output.append("\n" INDENT1 "[System.Flags]");
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n" INDENT1 "public enum ");
p_output.append(enum_proxy_name);
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
p_output.append(" : long");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("\n" OPEN_BLOCK_L1);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
const ConstantInterface &last = ienum.constants.back()->get();
for (const ConstantInterface &iconstant : ienum.constants) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (iconstant.const_doc && iconstant.const_doc->description.size()) {
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
String xml_summary = bbcode_to_xml(fix_doc_description(iconstant.const_doc->description), nullptr);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (summary_lines.size()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// <summary>\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
for (int i = 0; i < summary_lines.size(); i++) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// ");
p_output.append(summary_lines[i]);
p_output.append("\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// </summary>\n");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2);
p_output.append(iconstant.proxy_name);
p_output.append(" = ");
p_output.append(itos(iconstant.value));
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
p_output.append(&iconstant != &last ? ",\n" : "\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT1 CLOSE_BLOCK);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (enum_in_static_class) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT1 CLOSE_BLOCK);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(CLOSE_BLOCK); // end of namespace
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n#pragma warning restore CS1591\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
Error BindingsGenerator::generate_cs_core_project(const String &p_proj_dir) {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V(!initialized, ERR_UNCONFIGURED);
Make FileAccess and DirAccess classes reference counted.
2022-03-23 10:08:58 +01:00
Ref<DirAccess> da = DirAccess::create(DirAccess::ACCESS_FILESYSTEM);
ERR_FAIL_COND_V(da.is_null(), ERR_CANT_CREATE);
Added mono module
2017-10-02 23:24:00 +02:00
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
if (!DirAccess::exists(p_proj_dir)) {
Error err = da->make_dir_recursive(p_proj_dir);
Added some obvious errors explanations
2019-09-25 10:28:50 +02:00
ERR_FAIL_COND_V_MSG(err != OK, ERR_CANT_CREATE, "Cannot create directory '" + p_proj_dir + "'.");
Added mono module
2017-10-02 23:24:00 +02:00
}
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
da->change_dir(p_proj_dir);
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
da->make_dir("Generated");
da->make_dir("Generated/GodotObjects");
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String base_gen_dir = path::join(p_proj_dir, "Generated");
String godot_objects_gen_dir = path::join(base_gen_dir, "GodotObjects");
Vector<String> compile_items;
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Generate source file for global scope constants and enums
{
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
StringBuilder constants_source;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
_generate_global_constants(constants_source);
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String output_file = path::join(base_gen_dir, BINDINGS_GLOBAL_SCOPE_CLASS "_constants.cs");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Error save_err = _save_file(output_file, constants_source);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (save_err != OK) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
return save_err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(output_file);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Add C# array features from core PackedArrays
2021-01-13 11:17:39 +01:00
// Generate source file for array extensions
{
StringBuilder extensions_source;
_generate_array_extensions(extensions_source);
String output_file = path::join(base_gen_dir, BINDINGS_GLOBAL_SCOPE_CLASS "_extensions.cs");
Error save_err = _save_file(output_file, extensions_source);
if (save_err != OK) {
return save_err;
}
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(output_file);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
for (const KeyValue<StringName, TypeInterface> &E : obj_types) {
const TypeInterface &itype = E.value;
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (itype.api_type == ClassDB::API_EDITOR) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String output_file = path::join(godot_objects_gen_dir, itype.proxy_name + ".cs");
Mono: Fix iteration order of object types when generating bindings
2018-01-09 19:06:59 +01:00
Error err = _generate_cs_type(itype, output_file);
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err == ERR_SKIP) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Added mono module
2017-10-02 23:24:00 +02:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(output_file);
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Generate native calls
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
StringBuilder cs_icalls_content;
cs_icalls_content.append("using System;\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
"using System.Diagnostics.CodeAnalysis;\n"
"using System.Runtime.InteropServices;\n"
"using Godot.NativeInterop;\n"
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
"\n");
cs_icalls_content.append("namespace " BINDINGS_NAMESPACE "\n" OPEN_BLOCK);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"InconsistentNaming\")]\n");
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"RedundantUnsafeContext\")]\n");
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"RedundantNameQualifier\")]\n");
cs_icalls_content.append(INDENT1 "[System.Runtime.CompilerServices.SkipLocalsInit]\n");
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
cs_icalls_content.append(INDENT1 "internal static class " BINDINGS_CLASS_NATIVECALLS "\n" INDENT1 "{");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
cs_icalls_content.append(MEMBER_BEGIN "internal static ulong godot_api_hash = ");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(String::num_uint64(ClassDB::get_api_hash(ClassDB::API_CORE)) + ";\n");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(MEMBER_BEGIN "private const int VarArgsSpanThreshold = 10;\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
for (const InternalCall &icall : method_icalls) {
if (icall.editor_only) {
continue;
}
Error err = _generate_cs_native_calls(icall, cs_icalls_content);
if (err != OK) {
return err;
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
cs_icalls_content.append(INDENT1 CLOSE_BLOCK CLOSE_BLOCK);
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String internal_methods_file = path::join(base_gen_dir, BINDINGS_CLASS_NATIVECALLS ".cs");
Added mono module
2017-10-02 23:24:00 +02:00
Error err = _save_file(internal_methods_file, cs_icalls_content);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Added mono module
2017-10-02 23:24:00 +02:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(internal_methods_file);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Generate GeneratedIncludes.props
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
StringBuilder includes_props_content;
includes_props_content.append("<Project>\n"
" <ItemGroup>\n");
for (int i = 0; i < compile_items.size(); i++) {
String include = path::relative_to(compile_items[i], p_proj_dir).replace("/", "\\");
includes_props_content.append(" <Compile Include=\"" + include + "\" />\n");
}
includes_props_content.append(" </ItemGroup>\n"
"</Project>\n");
String includes_props_file = path::join(base_gen_dir, "GeneratedIncludes.props");
err = _save_file(includes_props_file, includes_props_content);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Exit after generating mono glue
2017-10-24 16:18:47 +02:00
Added mono module
2017-10-02 23:24:00 +02:00
return OK;
}
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
Error BindingsGenerator::generate_cs_editor_project(const String &p_proj_dir) {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V(!initialized, ERR_UNCONFIGURED);
Make FileAccess and DirAccess classes reference counted.
2022-03-23 10:08:58 +01:00
Ref<DirAccess> da = DirAccess::create(DirAccess::ACCESS_FILESYSTEM);
ERR_FAIL_COND_V(da.is_null(), ERR_CANT_CREATE);
Added mono module
2017-10-02 23:24:00 +02:00
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
if (!DirAccess::exists(p_proj_dir)) {
Error err = da->make_dir_recursive(p_proj_dir);
Added mono module
2017-10-02 23:24:00 +02:00
ERR_FAIL_COND_V(err != OK, ERR_CANT_CREATE);
}
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
da->change_dir(p_proj_dir);
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
da->make_dir("Generated");
da->make_dir("Generated/GodotObjects");
String base_gen_dir = path::join(p_proj_dir, "Generated");
String godot_objects_gen_dir = path::join(base_gen_dir, "GodotObjects");
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
Vector<String> compile_items;
Added mono module
2017-10-02 23:24:00 +02:00
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
for (const KeyValue<StringName, TypeInterface> &E : obj_types) {
const TypeInterface &itype = E.value;
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (itype.api_type != ClassDB::API_EDITOR) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String output_file = path::join(godot_objects_gen_dir, itype.proxy_name + ".cs");
Mono: Fix iteration order of object types when generating bindings
2018-01-09 19:06:59 +01:00
Error err = _generate_cs_type(itype, output_file);
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err == ERR_SKIP) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Added mono module
2017-10-02 23:24:00 +02:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(output_file);
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Generate native calls
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
StringBuilder cs_icalls_content;
cs_icalls_content.append("using System;\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
"using System.Diagnostics.CodeAnalysis;\n"
"using System.Runtime.InteropServices;\n"
"using Godot.NativeInterop;\n"
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
"\n");
cs_icalls_content.append("namespace " BINDINGS_NAMESPACE "\n" OPEN_BLOCK);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"InconsistentNaming\")]\n");
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"RedundantUnsafeContext\")]\n");
cs_icalls_content.append(INDENT1 "[SuppressMessage(\"ReSharper\", \"RedundantNameQualifier\")]\n");
cs_icalls_content.append(INDENT1 "[System.Runtime.CompilerServices.SkipLocalsInit]\n");
cs_icalls_content.append(INDENT1 "internal static class " BINDINGS_CLASS_NATIVECALLS_EDITOR "\n" OPEN_BLOCK_L1);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
cs_icalls_content.append(INDENT2 "internal static ulong godot_api_hash = ");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(String::num_uint64(ClassDB::get_api_hash(ClassDB::API_EDITOR)) + ";\n");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append(MEMBER_BEGIN "private const int VarArgsSpanThreshold = 10;\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_icalls_content.append("\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
for (const InternalCall &icall : method_icalls) {
if (!icall.editor_only) {
continue;
}
Error err = _generate_cs_native_calls(icall, cs_icalls_content);
if (err != OK) {
return err;
}
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
cs_icalls_content.append(INDENT1 CLOSE_BLOCK CLOSE_BLOCK);
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
String internal_methods_file = path::join(base_gen_dir, BINDINGS_CLASS_NATIVECALLS_EDITOR ".cs");
Added mono module
2017-10-02 23:24:00 +02:00
Error err = _save_file(internal_methods_file, cs_icalls_content);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Added mono module
2017-10-02 23:24:00 +02:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
compile_items.push_back(internal_methods_file);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Generate GeneratedIncludes.props
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
StringBuilder includes_props_content;
includes_props_content.append("<Project>\n"
" <ItemGroup>\n");
for (int i = 0; i < compile_items.size(); i++) {
String include = path::relative_to(compile_items[i], p_proj_dir).replace("/", "\\");
includes_props_content.append(" <Compile Include=\"" + include + "\" />\n");
}
includes_props_content.append(" </ItemGroup>\n"
"</Project>\n");
String includes_props_file = path::join(base_gen_dir, "GeneratedIncludes.props");
err = _save_file(includes_props_file, includes_props_content);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (err != OK) {
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
return err;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
return OK;
}
Added mono module
2017-10-02 23:24:00 +02:00
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
Error BindingsGenerator::generate_cs_api(const String &p_output_dir) {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V(!initialized, ERR_UNCONFIGURED);
Fix --generate-mono-glue bug when directory doesn't exist DirAccess::get_full_path(path) only works if the path exists. Implement our own abspath function.
2019-07-08 15:16:35 +02:00
String output_dir = path::abspath(path::realpath(p_output_dir));
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
Make FileAccess and DirAccess classes reference counted.
2022-03-23 10:08:58 +01:00
Ref<DirAccess> da = DirAccess::create(DirAccess::ACCESS_FILESYSTEM);
ERR_FAIL_COND_V(da.is_null(), ERR_CANT_CREATE);
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
if (!DirAccess::exists(output_dir)) {
Error err = da->make_dir_recursive(output_dir);
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
ERR_FAIL_COND_V(err != OK, ERR_CANT_CREATE);
}
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
Error proj_err;
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
// Generate GodotSharp source files
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
String core_proj_dir = output_dir.plus_file(CORE_API_ASSEMBLY_NAME);
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
proj_err = generate_cs_core_project(core_proj_dir);
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
if (proj_err != OK) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
ERR_PRINT("Generation of the Core API C# project failed.");
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
return proj_err;
}
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
// Generate GodotSharpEditor source files
String editor_proj_dir = output_dir.plus_file(EDITOR_API_ASSEMBLY_NAME);
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
proj_err = generate_cs_editor_project(editor_proj_dir);
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
if (proj_err != OK) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
ERR_PRINT("Generation of the Editor API C# project failed.");
Improve the C# API projects generation - Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project - GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly - This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
2018-11-08 01:05:19 +01:00
return proj_err;
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 19:12:32 +01:00
_log("The Godot API sources were successfully generated\n");
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
Added mono module
2017-10-02 23:24:00 +02:00
return OK;
}
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
// FIXME: There are some members that hide other inherited members.
// - In the case of both members being the same kind, the new one must be declared
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
// explicitly as 'new' to avoid the warning (and we must print a message about it).
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
// - In the case of both members being of a different kind, then the new one must
// be renamed to avoid the name collision (and we must print a warning about it).
// - Csc warning e.g.:
// ObjectType/LineEdit.cs(140,38): warning CS0108: 'LineEdit.FocusMode' hides inherited member 'Control.FocusMode'. Use the new keyword if hiding was intended.
Added mono module
2017-10-02 23:24:00 +02:00
Error BindingsGenerator::_generate_cs_type(const TypeInterface &itype, const String &p_output_file) {
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
CRASH_COND(!itype.is_object_type);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
bool is_derived_type = itype.base_name != StringName();
Added mono module
2017-10-02 23:24:00 +02:00
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (!is_derived_type) {
// Some Godot.Object assertions
CRASH_COND(itype.cname != name_cache.type_Object);
CRASH_COND(!itype.is_instantiable);
CRASH_COND(itype.api_type != ClassDB::API_CORE);
Rename Reference to RefCounted
2021-06-04 18:03:15 +02:00
CRASH_COND(itype.is_ref_counted);
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
CRASH_COND(itype.is_singleton);
}
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
_log("Generating %s.cs...\n", itype.proxy_name.utf8().get_data());
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
StringBuilder output;
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append("using System;\n"); // IntPtr
output.append("using System.Diagnostics;\n"); // DebuggerBrowsable
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
output.append("using Godot.NativeInterop;\n");
C# API: Hide method bind fields from debugger
2018-10-16 17:22:27 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append("\n"
"#pragma warning disable CS1591 // Disable warning: "
"'Missing XML comment for publicly visible type or member'\n"
"#pragma warning disable CS1573 // Disable warning: "
"'Parameter has no matching param tag in the XML comment'\n");
C# API: Hide method bind fields from debugger
2018-10-16 17:22:27 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
output.append("\n#nullable disable\n");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append("\nnamespace " BINDINGS_NAMESPACE "\n" OPEN_BLOCK);
Added mono module
2017-10-02 23:24:00 +02:00
const DocData::ClassDoc *class_doc = itype.class_doc;
if (class_doc && class_doc->description.size()) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String xml_summary = bbcode_to_xml(fix_doc_description(class_doc->description), &itype);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (summary_lines.size()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(INDENT1 "/// <summary>\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
for (int i = 0; i < summary_lines.size(); i++) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(INDENT1 "/// ");
output.append(summary_lines[i]);
output.append("\n");
Added mono module
2017-10-02 23:24:00 +02:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(INDENT1 "/// </summary>\n");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Add source generator for properties and exports default values The editor no longer needs to create temporary instances to get the default values. The initializer values of the exported properties are still evaluated at runtime. For example, in the following example, `GetInitialValue()` will be called when first looks for default values: ``` [Export] int MyValue = GetInitialValue(); ``` Exporting fields with a non-supported type now results in a compiler error rather than a runtime error when the script is used.
2022-02-27 21:57:30 +01:00
// We generate a `GodotClassName` attribute if the engine class name is not the same as the
// generated C# class name. This allows introspection code to find the name associated with
// the class. If the attribute is not present, the C# class name can be used instead.
if (itype.name != itype.proxy_name) {
output << INDENT1 "[GodotClassName(\"" << itype.name << "\")]\n";
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(INDENT1 "public ");
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (itype.is_singleton) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append("static partial class ");
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
} else {
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
// Even if the class is not instantiable, we can't declare it abstract because
// the engine can still instantiate them and return them via the scripting API.
// Example: `SceneTreeTimer` returned from `SceneTree.create_timer`.
// See the reverted commit: ef5672d3f94a7321ed779c922088bb72adbb1521
output.append("partial class ");
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(itype.proxy_name);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (is_derived_type && !itype.is_singleton) {
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (obj_types.has(itype.base_name)) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(" : ");
output.append(obj_types[itype.base_name].proxy_name);
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
} else {
Remove duplicate ERR_PRINT macro.
2019-11-06 17:03:04 +01:00
ERR_PRINT("Base type '" + itype.base_name.operator String() + "' does not exist, for class '" + itype.name + "'.");
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
return ERR_INVALID_DATA;
}
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
output.append("\n" INDENT1 "{");
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
// Add constants
Added mono module
2017-10-02 23:24:00 +02:00
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const ConstantInterface &iconstant : itype.constants) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iconstant.const_doc && iconstant.const_doc->description.size()) {
String xml_summary = bbcode_to_xml(fix_doc_description(iconstant.const_doc->description), &itype);
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (summary_lines.size()) {
output.append(MEMBER_BEGIN "/// <summary>\n");
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
for (int i = 0; i < summary_lines.size(); i++) {
output.append(INDENT2 "/// ");
output.append(summary_lines[i]);
output.append("\n");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(INDENT2 "/// </summary>");
}
Added mono module
2017-10-02 23:24:00 +02:00
}
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
output.append(MEMBER_BEGIN "public const long ");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(iconstant.proxy_name);
output.append(" = ");
output.append(itos(iconstant.value));
output.append(";");
}
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (itype.constants.size()) {
output.append("\n");
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
// Add enums
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const EnumInterface &ienum : itype.enums) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
ERR_FAIL_COND_V(ienum.constants.is_empty(), ERR_BUG);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Add C# support for bitfield enums (flags)
2022-06-24 20:25:30 +02:00
if (ienum.is_flags) {
output.append(MEMBER_BEGIN "[System.Flags]");
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(MEMBER_BEGIN "public enum ");
output.append(ienum.cname.operator String());
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
output.append(" : long");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(MEMBER_BEGIN OPEN_BLOCK);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
const ConstantInterface &last = ienum.constants.back()->get();
for (const ConstantInterface &iconstant : ienum.constants) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iconstant.const_doc && iconstant.const_doc->description.size()) {
String xml_summary = bbcode_to_xml(fix_doc_description(iconstant.const_doc->description), &itype);
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (summary_lines.size()) {
output.append(INDENT3 "/// <summary>\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
for (int i = 0; i < summary_lines.size(); i++) {
output.append(INDENT3 "/// ");
output.append(summary_lines[i]);
output.append("\n");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(INDENT3 "/// </summary>\n");
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(INDENT3);
output.append(iconstant.proxy_name);
output.append(" = ");
output.append(itos(iconstant.value));
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
output.append(&iconstant != &last ? ",\n" : "\n");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
output.append(INDENT2 CLOSE_BLOCK);
Added mono module
2017-10-02 23:24:00 +02:00
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
// Add properties
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const PropertyInterface &iprop : itype.properties) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
Error prop_err = _generate_cs_property(itype, iprop, output);
ERR_FAIL_COND_V_MSG(prop_err != OK, prop_err,
"Failed to generate property '" + iprop.cname.operator String() +
"' for class '" + itype.name + "'.");
}
Use script instance binding for objects constructed from C# Only possible if the object class is a "native type". If the object class is a user class (that derives a "native type") then a script is needed. Since CSharpLanguage does cleanup of script instance bindings when finished, cases like #25621 will no longer cause problems. Fixed ~Object() trying to free script instance bindings after the language has already been removed, which would result in a NULL dereference.
2019-02-04 20:39:02 +01:00
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (itype.is_singleton) {
Added mono module
2017-10-02 23:24:00 +02:00
// Add the type name and the singleton pointer as static fields
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(MEMBER_BEGIN "private static Godot.Object singleton;\n");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
output << MEMBER_BEGIN "public static Godot.Object " CS_PROPERTY_SINGLETON "\n" INDENT2 "{\n"
<< INDENT3 "get\n" INDENT3 "{\n" INDENT4 "if (singleton == null)\n"
<< INDENT5 "singleton = " C_METHOD_ENGINE_GET_SINGLETON "(typeof("
<< itype.proxy_name
<< ").Name);\n" INDENT4 "return singleton;\n" INDENT3 "}\n" INDENT2 "}\n";
output.append(MEMBER_BEGIN "private static readonly StringName " BINDINGS_NATIVE_NAME_FIELD " = \"");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(itype.name);
output.append("\";\n");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else {
// IMPORTANT: We also generate the static fields for Godot.Object instead of declaring
// them manually in the `Object.base.cs` partial class declaration, because they're
// required by other static fields in this generated partial class declaration.
// Static fields are initialized in order of declaration, but when they're in different
// partial class declarations then it becomes harder to tell (Rider warns about this).
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Add native name static field
Added mono module
2017-10-02 23:24:00 +02:00
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
if (is_derived_type) {
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
output << MEMBER_BEGIN "private static readonly System.Type CachedType = typeof(" << itype.proxy_name << ");\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
output.append(MEMBER_BEGIN "private static readonly StringName " BINDINGS_NATIVE_NAME_FIELD " = \"");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(itype.name);
output.append("\";\n");
Added mono module
2017-10-02 23:24:00 +02:00
if (itype.is_instantiable) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Add native constructor static field
output << MEMBER_BEGIN << "[DebuggerBrowsable(DebuggerBrowsableState.Never)]\n"
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
<< INDENT2 "private static readonly unsafe delegate* unmanaged<IntPtr> "
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
<< CS_STATIC_FIELD_NATIVE_CTOR " = " ICALL_CLASSDB_GET_CONSTRUCTOR
C#: Begin move to .NET Core We're targeting .NET 5 for now to make development easier while .NET 6 is not yet released. TEMPORARY REGRESSIONS --------------------- Assembly unloading is not implemented yet. As such, many Godot resources are leaked at exit. This will be re-implemented later together with assembly hot-reloading.
2021-09-12 20:23:05 +02:00
<< "(" BINDINGS_NATIVE_NAME_FIELD ");\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
}
if (is_derived_type) {
// Add default constructor
if (itype.is_instantiable) {
output << MEMBER_BEGIN "public " << itype.proxy_name << "() : this("
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
<< (itype.memory_own ? "true" : "false") << ")\n" OPEN_BLOCK_L2
<< INDENT3 "unsafe\n" INDENT3 OPEN_BLOCK
<< INDENT4 "_ConstructAndInitialize(" CS_STATIC_FIELD_NATIVE_CTOR ", "
<< BINDINGS_NATIVE_NAME_FIELD ", CachedType, refCounted: "
<< (itype.is_ref_counted ? "true" : "false") << ");\n"
<< CLOSE_BLOCK_L3 CLOSE_BLOCK_L2;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else {
// Hide the constructor
output.append(MEMBER_BEGIN "internal ");
output.append(itype.proxy_name);
output.append("() {}\n");
}
// Add.. em.. trick constructor. Sort of.
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(MEMBER_BEGIN "internal ");
output.append(itype.proxy_name);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
output.append("(bool " CS_PARAM_MEMORYOWN ") : base(" CS_PARAM_MEMORYOWN ") {}\n");
Added mono module
2017-10-02 23:24:00 +02:00
}
}
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
// Methods
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
int method_bind_count = 0;
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const MethodInterface &imethod : itype.methods) {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
Error method_err = _generate_cs_method(itype, imethod, method_bind_count, output);
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
ERR_FAIL_COND_V_MSG(method_err != OK, method_err,
"Failed to generate method '" + imethod.name + "' for class '" + itype.name + "'.");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
// Signals
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const SignalInterface &isignal : itype.signals_) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
Error method_err = _generate_cs_signal(itype, isignal, output);
ERR_FAIL_COND_V_MSG(method_err != OK, method_err,
"Failed to generate signal '" + isignal.name + "' for class '" + itype.name + "'.");
}
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
// Script members look-up
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
if (!itype.is_singleton && (is_derived_type || itype.has_virtual_methods)) {
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
// Generate method names cache fields
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
for (const MethodInterface &imethod : itype.methods) {
if (!imethod.is_virtual) {
continue;
}
output << MEMBER_BEGIN "// ReSharper disable once InconsistentNaming\n"
<< INDENT2 "[DebuggerBrowsable(DebuggerBrowsableState.Never)]\n"
<< INDENT2 "private static readonly StringName "
<< CS_STATIC_FIELD_METHOD_NAME_PREFIX << imethod.name
<< " = \"" << imethod.name << "\";\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
output << MEMBER_BEGIN "// ReSharper disable once InconsistentNaming\n"
<< INDENT2 "[DebuggerBrowsable(DebuggerBrowsableState.Never)]\n"
<< INDENT2 "private static readonly StringName "
<< CS_STATIC_FIELD_METHOD_PROXY_NAME_PREFIX << imethod.name
<< " = \"" << imethod.proxy_name << "\";\n";
}
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
// TODO: Only generate HasGodotClassMethod and InvokeGodotClassMethod if there's any method
// Generate InvokeGodotClassMethod
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
output << MEMBER_BEGIN "protected internal " << (is_derived_type ? "override" : "virtual")
<< " bool " CS_METHOD_INVOKE_GODOT_CLASS_METHOD "(in godot_string_name method, "
<< "NativeVariantPtrArgs args, int argCount, out godot_variant ret)\n"
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
<< INDENT2 "{\n";
for (const MethodInterface &imethod : itype.methods) {
if (!imethod.is_virtual) {
continue;
}
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
// We also call HasGodotClassMethod to ensure the method is overridden and avoid calling
// the stub implementation. This solution adds some extra overhead to calls, but it's
// much simpler than other solutions. This won't be a problem once we move to function
// pointers of generated wrappers for each method, as lookup will only happen once.
// We check both native names (snake_case) and proxy names (PascalCase)
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
output << INDENT3 "if ((method == " << CS_STATIC_FIELD_METHOD_PROXY_NAME_PREFIX << imethod.name
<< " || method == " << CS_STATIC_FIELD_METHOD_NAME_PREFIX << imethod.name
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
<< ") && argCount == " << itos(imethod.arguments.size())
<< " && " << CS_METHOD_HAS_GODOT_CLASS_METHOD << "((godot_string_name)"
<< CS_STATIC_FIELD_METHOD_PROXY_NAME_PREFIX << imethod.name << ".NativeValue))\n"
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
<< INDENT3 "{\n";
if (imethod.return_type.cname != name_cache.type_void) {
output << INDENT4 "object retBoxed = ";
} else {
output << INDENT4;
}
output << imethod.proxy_name << "(";
for (int i = 0; i < imethod.arguments.size(); i++) {
const ArgumentInterface &iarg = imethod.arguments[i];
const TypeInterface *arg_type = _get_type_or_null(iarg.type);
ERR_FAIL_NULL_V(arg_type, ERR_BUG); // Argument type not found
if (i != 0) {
output << ", ";
}
// TODO: static marshaling (no reflection, no runtime type checks)
if (arg_type->cname == name_cache.type_Array_generic || arg_type->cname == name_cache.type_Dictionary_generic) {
String arg_cs_type = arg_type->cs_type + _get_generic_type_parameters(*arg_type, iarg.type.generic_type_parameters);
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
output << "new " << arg_cs_type << "((" << arg_type->cs_type << ")Marshaling.ConvertVariantToManagedObjectOfType(args["
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
<< itos(i) << "], typeof(" << arg_type->cs_type << ")))";
} else {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
output << "(" << arg_type->cs_type << ")Marshaling.ConvertVariantToManagedObjectOfType(args["
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
<< itos(i) << "], typeof(" << arg_type->cs_type << "))";
}
}
output << ");\n";
if (imethod.return_type.cname != name_cache.type_void) {
// TODO: static marshaling (no reflection, no runtime type checks)
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
output << INDENT4 "ret = Marshaling.ConvertManagedObjectToVariant(retBoxed);\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
output << INDENT4 "return true;\n";
} else {
output << INDENT4 "ret = default;\n";
output << INDENT4 "return true;\n";
}
output << INDENT3 "}\n";
}
if (is_derived_type) {
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
output << INDENT3 "return base." CS_METHOD_INVOKE_GODOT_CLASS_METHOD "(method, args, argCount, out ret);\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
} else {
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
output << INDENT3 "ret = default;\n"
<< INDENT3 "return false;\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
}
output << INDENT2 "}\n";
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
// Generate HasGodotClassMethod
output << MEMBER_BEGIN "protected internal " << (is_derived_type ? "override" : "virtual")
<< " bool " CS_METHOD_HAS_GODOT_CLASS_METHOD "(in godot_string_name method)\n"
<< INDENT2 "{\n";
for (const MethodInterface &imethod : itype.methods) {
if (!imethod.is_virtual) {
continue;
}
// We check for native names (snake_case). If we detect one, we call HasGodotClassMethod
// again, but this time with the respective proxy name (PascalCase). It's the job of
// user derived classes to override the method and check for those. Our C# source
// generators take care of generating those override methods.
output << INDENT3 "if (method == " << CS_STATIC_FIELD_METHOD_NAME_PREFIX << imethod.name
<< ")\n" INDENT3 "{\n"
<< INDENT4 "if (" CS_METHOD_HAS_GODOT_CLASS_METHOD "("
<< CS_STATIC_FIELD_METHOD_PROXY_NAME_PREFIX << imethod.name
<< ".NativeValue.DangerousSelfRef))\n" INDENT4 "{\n"
<< INDENT5 "return true;\n"
<< INDENT4 "}\n" INDENT3 "}\n";
}
if (is_derived_type) {
output << INDENT3 "return base." CS_METHOD_HAS_GODOT_CLASS_METHOD "(method);\n";
} else {
output << INDENT3 "return false;\n";
}
output << INDENT2 "}\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append(INDENT1 CLOSE_BLOCK /* class */
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
CLOSE_BLOCK /* namespace */);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
output.append("\n"
"#pragma warning restore CS1591\n"
"#pragma warning restore CS1573\n");
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return _save_file(p_output_file, output);
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Error BindingsGenerator::_generate_cs_property(const BindingsGenerator::TypeInterface &p_itype, const PropertyInterface &p_iprop, StringBuilder &p_output) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
const MethodInterface *setter = p_itype.find_method_by_name(p_iprop.setter);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Search it in base types too
const TypeInterface *current_type = &p_itype;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
while (!setter && current_type->base_name != StringName()) {
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
HashMap<StringName, TypeInterface>::Iterator base_match = obj_types.find(current_type->base_name);
Fix C# bindings after recent breaking changes
2020-04-03 01:38:48 +02:00
ERR_FAIL_COND_V_MSG(!base_match, ERR_BUG, "Type not found '" + current_type->base_name + "'. Inherited by '" + current_type->name + "'.");
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
current_type = &base_match->value;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
setter = current_type->find_method_by_name(p_iprop.setter);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
const MethodInterface *getter = p_itype.find_method_by_name(p_iprop.getter);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Search it in base types too
current_type = &p_itype;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
while (!getter && current_type->base_name != StringName()) {
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
HashMap<StringName, TypeInterface>::Iterator base_match = obj_types.find(current_type->base_name);
Fix C# bindings after recent breaking changes
2020-04-03 01:38:48 +02:00
ERR_FAIL_COND_V_MSG(!base_match, ERR_BUG, "Type not found '" + current_type->base_name + "'. Inherited by '" + current_type->name + "'.");
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
current_type = &base_match->value;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
getter = current_type->find_method_by_name(p_iprop.getter);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
ERR_FAIL_COND_V(!setter && !getter, ERR_BUG);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (setter) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
int setter_argc = p_iprop.index != -1 ? 2 : 1;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
ERR_FAIL_COND_V(setter->arguments.size() != setter_argc, ERR_BUG);
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (getter) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
int getter_argc = p_iprop.index != -1 ? 1 : 0;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
ERR_FAIL_COND_V(getter->arguments.size() != getter_argc, ERR_BUG);
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (getter && setter) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
const ArgumentInterface &setter_first_arg = setter->arguments.back()->get();
if (getter->return_type.cname != setter_first_arg.type.cname) {
// Special case for Node::set_name
bool whitelisted = getter->return_type.cname == name_cache.type_StringName &&
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
setter_first_arg.type.cname == name_cache.type_String;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
ERR_FAIL_COND_V_MSG(!whitelisted, ERR_BUG,
"Return type from getter doesn't match first argument of setter for property: '" +
p_itype.name + "." + String(p_iprop.cname) + "'.");
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
const TypeReference &proptype_name = getter ? getter->return_type : setter->arguments.back()->get().type;
Added mono module
2017-10-02 23:24:00 +02:00
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
const TypeInterface *prop_itype = _get_type_or_null(proptype_name);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
ERR_FAIL_NULL_V(prop_itype, ERR_BUG); // Property type not found
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(prop_itype->is_singleton, ERR_BUG,
"Property type is a singleton: '" + p_itype.name + "." + String(p_iprop.cname) + "'.");
Add ClassDB tests to look for core API deps on editor API The ClassDB tests will detect when the core API has dependencies on the editor API, which is not allowed. This should prevent or warn early about issues like #44856
2021-01-09 00:14:25 +01:00
if (p_itype.api_type == ClassDB::API_CORE) {
ERR_FAIL_COND_V_MSG(prop_itype->api_type == ClassDB::API_EDITOR, ERR_BUG,
"Property '" + p_itype.name + "." + String(p_iprop.cname) + "' has type '" + prop_itype->name +
"' from the editor API. Core API cannot have dependencies on the editor API.");
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (p_iprop.prop_doc && p_iprop.prop_doc->description.size()) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String xml_summary = bbcode_to_xml(fix_doc_description(p_iprop.prop_doc->description), &p_itype);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
if (summary_lines.size()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(MEMBER_BEGIN "/// <summary>\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
for (int i = 0; i < summary_lines.size(); i++) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// ");
p_output.append(summary_lines[i]);
p_output.append("\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// </summary>");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(MEMBER_BEGIN "public ");
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (p_itype.is_singleton) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("static ");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
String prop_cs_type = prop_itype->cs_type + _get_generic_type_parameters(*prop_itype, proptype_name.generic_type_parameters);
p_output.append(prop_cs_type);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(" ");
p_output.append(p_iprop.proxy_name);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("\n" OPEN_BLOCK_L2);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (getter) {
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
p_output.append(INDENT3 "get\n"
// TODO Remove this once we make accessor methods private/internal (they will no longer be marked as obsolete after that)
"#pragma warning disable CS0618 // Disable warning about obsolete method\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
OPEN_BLOCK_L3 INDENT4);
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("return ");
p_output.append(getter->proxy_name + "(");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (p_iprop.index != -1) {
const ArgumentInterface &idx_arg = getter->arguments.front()->get();
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
if (idx_arg.type.cname != name_cache.type_int) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Assume the index parameter is an enum
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
const TypeInterface *idx_arg_type = _get_type_or_null(idx_arg.type);
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
CRASH_COND(idx_arg_type == nullptr);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("(" + idx_arg_type->proxy_name + ")" + itos(p_iprop.index));
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
} else {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(itos(p_iprop.index));
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
}
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
p_output.append(");\n"
CLOSE_BLOCK_L3
// TODO Remove this once we make accessor methods private/internal (they will no longer be marked as obsolete after that)
"#pragma warning restore CS0618\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (setter) {
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
p_output.append(INDENT3 "set\n"
// TODO Remove this once we make accessor methods private/internal (they will no longer be marked as obsolete after that)
"#pragma warning disable CS0618 // Disable warning about obsolete method\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
OPEN_BLOCK_L3 INDENT4);
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(setter->proxy_name + "(");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (p_iprop.index != -1) {
const ArgumentInterface &idx_arg = setter->arguments.front()->get();
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
if (idx_arg.type.cname != name_cache.type_int) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Assume the index parameter is an enum
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
const TypeInterface *idx_arg_type = _get_type_or_null(idx_arg.type);
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
CRASH_COND(idx_arg_type == nullptr);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("(" + idx_arg_type->proxy_name + ")" + itos(p_iprop.index) + ", ");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
} else {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(itos(p_iprop.index) + ", ");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
}
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
p_output.append("value);\n"
CLOSE_BLOCK_L3
// TODO Remove this once we make accessor methods private/internal (they will no longer be marked as obsolete after that)
"#pragma warning restore CS0618\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(CLOSE_BLOCK_L2);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return OK;
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Error BindingsGenerator::_generate_cs_method(const BindingsGenerator::TypeInterface &p_itype, const BindingsGenerator::MethodInterface &p_imethod, int &p_method_bind_count, StringBuilder &p_output) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *return_type = _get_type_or_null(p_imethod.return_type);
ERR_FAIL_NULL_V(return_type, ERR_BUG); // Return type not found
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(return_type->is_singleton, ERR_BUG,
"Method return type is a singleton: '" + p_itype.name + "." + p_imethod.name + "'.");
Add ClassDB tests to look for core API deps on editor API The ClassDB tests will detect when the core API has dependencies on the editor API, which is not allowed. This should prevent or warn early about issues like #44856
2021-01-09 00:14:25 +01:00
if (p_itype.api_type == ClassDB::API_CORE) {
ERR_FAIL_COND_V_MSG(return_type->api_type == ClassDB::API_EDITOR, ERR_BUG,
"Method '" + p_itype.name + "." + p_imethod.name + "' has return type '" + return_type->name +
"' from the editor API. Core API cannot have dependencies on the editor API.");
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
String method_bind_field = CS_STATIC_FIELD_METHOD_BIND_PREFIX + itos(p_method_bind_count);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
String arguments_sig;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
StringBuilder cs_in_statements;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
bool cs_in_expr_is_unsafe = false;
Added mono module
2017-10-02 23:24:00 +02:00
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
String icall_params = method_bind_field;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
if (!p_imethod.is_static) {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (p_itype.cs_in.size()) {
cs_in_statements << sformat(p_itype.cs_in, p_itype.c_type, "this",
String(), String(), String(), INDENT3);
}
icall_params += ", " + sformat(p_itype.cs_in_expr, "this");
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
}
Mono: Fix NodePath and RID bindings
2018-01-25 23:44:37 +01:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
StringBuilder default_args_doc;
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Retrieve information from the arguments
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
const ArgumentInterface &first = p_imethod.arguments.front()->get();
for (const ArgumentInterface &iarg : p_imethod.arguments) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *arg_type = _get_type_or_null(iarg.type);
ERR_FAIL_NULL_V(arg_type, ERR_BUG); // Argument type not found
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(arg_type->is_singleton, ERR_BUG,
"Argument type is a singleton: '" + iarg.name + "' of method '" + p_itype.name + "." + p_imethod.name + "'.");
Add ClassDB tests to look for core API deps on editor API The ClassDB tests will detect when the core API has dependencies on the editor API, which is not allowed. This should prevent or warn early about issues like #44856
2021-01-09 00:14:25 +01:00
if (p_itype.api_type == ClassDB::API_CORE) {
ERR_FAIL_COND_V_MSG(arg_type->api_type == ClassDB::API_EDITOR, ERR_BUG,
"Argument '" + iarg.name + "' of method '" + p_itype.name + "." + p_imethod.name + "' has type '" +
arg_type->name + "' from the editor API. Core API cannot have dependencies on the editor API.");
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.default_argument.size()) {
CRASH_COND_MSG(!_arg_default_value_is_assignable_to_type(iarg.def_param_value, *arg_type),
"Invalid default value for parameter '" + iarg.name + "' of method '" + p_itype.name + "." + p_imethod.name + "'.");
}
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
String arg_cs_type = arg_type->cs_type + _get_generic_type_parameters(*arg_type, iarg.type.generic_type_parameters);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Add the current arguments to the signature
// If the argument has a default value which is not a constant, we will make it Nullable
{
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
if (&iarg != &first) {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += ", ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.def_param_mode == ArgumentInterface::NULLABLE_VAL) {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += "Nullable<";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
arguments_sig += arg_cs_type;
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.def_param_mode == ArgumentInterface::NULLABLE_VAL) {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += "> ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += " ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += iarg.name;
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (iarg.default_argument.size()) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.def_param_mode != ArgumentInterface::CONSTANT) {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += " = null";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
arguments_sig += " = " + sformat(iarg.default_argument, arg_type->cs_type);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
}
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
icall_params += ", ";
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (iarg.default_argument.size() && iarg.def_param_mode != ArgumentInterface::CONSTANT) {
// The default value of an argument must be constant. Otherwise we make it Nullable and do the following:
// Type arg_in = arg.HasValue ? arg.Value : <non-const default value>;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
String arg_or_defval_local = iarg.name;
arg_or_defval_local += "OrDefVal";
Added mono module
2017-10-02 23:24:00 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
cs_in_statements << INDENT3 << arg_cs_type << " " << arg_or_defval_local << " = " << iarg.name;
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.def_param_mode == ArgumentInterface::NULLABLE_VAL) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << ".HasValue ? ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << " != null ? ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << iarg.name;
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iarg.def_param_mode == ArgumentInterface::NULLABLE_VAL) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << ".Value : ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << " : ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
String cs_type = arg_cs_type;
Use Array.Empty instead of allocating a every time Use `System.Array.Empty<T>` to get an empty array instead of allocating a new one every time. Since arrays are immutable there is no need to allocate them every time.
2021-07-25 13:46:31 +02:00
if (cs_type.ends_with("[]")) {
cs_type = cs_type.substr(0, cs_type.length() - 2);
}
String def_arg = sformat(iarg.default_argument, cs_type);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cs_in_statements << def_arg << ";\n";
Added mono module
2017-10-02 23:24:00 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (arg_type->cs_in.size()) {
cs_in_statements << sformat(arg_type->cs_in, arg_type->c_type, arg_or_defval_local,
String(), String(), String(), INDENT3);
}
if (arg_type->cs_in_expr.is_empty()) {
icall_params += arg_or_defval_local;
} else {
icall_params += sformat(arg_type->cs_in_expr, arg_or_defval_local, arg_type->c_type);
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
// Apparently the name attribute must not include the @
String param_tag_name = iarg.name.begins_with("@") ? iarg.name.substr(1, iarg.name.length()) : iarg.name;
Use Array.Empty instead of allocating a every time Use `System.Array.Empty<T>` to get an empty array instead of allocating a new one every time. Since arrays are immutable there is no need to allocate them every time.
2021-07-25 13:46:31 +02:00
// Escape < and > in the attribute default value
String param_def_arg = def_arg.replacen("<", "&lt;").replacen(">", "&gt;");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
default_args_doc.append(MEMBER_BEGIN "/// <param name=\"" + param_tag_name + "\">If the parameter is null, then the default value is <c>" + param_def_arg + "</c>.</param>");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
} else {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (arg_type->cs_in.size()) {
cs_in_statements << sformat(arg_type->cs_in, arg_type->c_type, iarg.name,
String(), String(), String(), INDENT3);
}
icall_params += arg_type->cs_in_expr.is_empty() ? iarg.name : sformat(arg_type->cs_in_expr, iarg.name, arg_type->c_type);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
cs_in_expr_is_unsafe |= arg_type->cs_in_expr_is_unsafe;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Generate method
{
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
if (!p_imethod.is_virtual && !p_imethod.requires_object_call) {
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
p_output << MEMBER_BEGIN "[DebuggerBrowsable(DebuggerBrowsableState.Never)]\n"
<< INDENT2 "private static readonly IntPtr " << method_bind_field << " = ";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (p_itype.is_singleton) {
// Singletons are static classes. They don't derive Godot.Object,
// so we need to specify the type to call the static method.
p_output << "Object.";
}
p_output << ICALL_CLASSDB_GET_METHOD "(" BINDINGS_NATIVE_NAME_FIELD ", \""
<< p_imethod.name
<< "\");\n";
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (p_imethod.method_doc && p_imethod.method_doc->description.size()) {
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
String xml_summary = bbcode_to_xml(fix_doc_description(p_imethod.method_doc->description), &p_itype);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Fix comment generation for non-constant param default - Generate the comment for the param, even if the method has no description. - Generate the comment outside the <summary> element.
2020-01-02 18:09:59 +01:00
if (summary_lines.size()) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(MEMBER_BEGIN "/// <summary>\n");
Added mono module
2017-10-02 23:24:00 +02:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
for (int i = 0; i < summary_lines.size(); i++) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// ");
p_output.append(summary_lines[i]);
p_output.append("\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(INDENT2 "/// </summary>");
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono/C#: Fix comment generation for non-constant param default - Generate the comment for the param, even if the method has no description. - Generate the comment outside the <summary> element.
2020-01-02 18:09:59 +01:00
if (default_args_doc.get_string_length()) {
p_output.append(default_args_doc.as_string());
}
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
if (p_imethod.is_deprecated) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (p_imethod.deprecation_message.is_empty()) {
Remove duplicate WARN_PRINT macro.
2019-11-07 09:44:15 +01:00
WARN_PRINT("An empty deprecation message is discouraged. Method: '" + p_imethod.proxy_name + "'.");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
p_output.append(MEMBER_BEGIN "[Obsolete(\"");
p_output.append(p_imethod.deprecation_message);
p_output.append("\")]");
}
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(MEMBER_BEGIN);
p_output.append(p_imethod.is_internal ? "internal " : "public ");
Added mono module
2017-10-02 23:24:00 +02:00
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
if (p_itype.is_singleton || p_imethod.is_static) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("static ");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
} else if (p_imethod.is_virtual) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("virtual ");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (cs_in_expr_is_unsafe) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("unsafe ");
}
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
String return_cs_type = return_type->cs_type + _get_generic_type_parameters(*return_type, p_imethod.return_type.generic_type_parameters);
p_output.append(return_cs_type + " ");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(p_imethod.proxy_name + "(");
p_output.append(arguments_sig + ")\n" OPEN_BLOCK_L2);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (p_imethod.is_virtual) {
// Godot virtual method must be overridden, therefore we return a default value by default.
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (return_type->cname == name_cache.type_void) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(CLOSE_BLOCK_L2);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(INDENT3 "return default;\n" CLOSE_BLOCK_L2);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return OK; // Won't increment method bind count
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (p_imethod.requires_object_call) {
// Fallback to Godot's object.Call(string, params)
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(INDENT3 CS_METHOD_CALL "(\"");
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(p_imethod.name);
p_output.append("\"");
Added mono module
2017-10-02 23:24:00 +02:00
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const ArgumentInterface &iarg : p_imethod.arguments) {
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(", ");
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
p_output.append(iarg.name);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(");\n" CLOSE_BLOCK_L2);
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return OK; // Won't increment method bind count
}
Added mono module
2017-10-02 23:24:00 +02:00
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<const MethodInterface *, const InternalCall *>::ConstIterator match = method_icalls_map.find(&p_imethod);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
ERR_FAIL_NULL_V(match, ERR_BUG);
Added mono module
2017-10-02 23:24:00 +02:00
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
const InternalCall *im_icall = match->value;
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Better versioning and gracefully unloading of Godot API assemblies
2018-02-22 13:13:51 +01:00
String im_call = im_icall->editor_only ? BINDINGS_CLASS_NATIVECALLS_EDITOR : BINDINGS_CLASS_NATIVECALLS;
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
im_call += ".";
im_call += im_icall->name;
Added mono module
2017-10-02 23:24:00 +02:00
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (p_imethod.arguments.size() && cs_in_statements.get_string_length() > 0) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(cs_in_statements.as_string());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (return_type->cname == name_cache.type_void) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output << INDENT3 << im_call << "(" << icall_params << ");\n";
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
} else if (return_type->cs_out.is_empty()) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output << INDENT3 "return " << im_call << "(" << icall_params << ");\n";
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(sformat(return_type->cs_out, im_call, icall_params,
return_cs_type, return_type->c_type_out, String(), INDENT3));
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append("\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
p_output.append(CLOSE_BLOCK_L2);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
p_method_bind_count++;
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return OK;
}
Added mono module
2017-10-02 23:24:00 +02:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
Error BindingsGenerator::_generate_cs_signal(const BindingsGenerator::TypeInterface &p_itype, const BindingsGenerator::SignalInterface &p_isignal, StringBuilder &p_output) {
String arguments_sig;
// Retrieve information from the arguments
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
const ArgumentInterface &first = p_isignal.arguments.front()->get();
for (const ArgumentInterface &iarg : p_isignal.arguments) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *arg_type = _get_type_or_null(iarg.type);
ERR_FAIL_NULL_V(arg_type, ERR_BUG); // Argument type not found
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(arg_type->is_singleton, ERR_BUG,
Add ClassDB tests to look for core API deps on editor API The ClassDB tests will detect when the core API has dependencies on the editor API, which is not allowed. This should prevent or warn early about issues like #44856
2021-01-09 00:14:25 +01:00
"Argument type is a singleton: '" + iarg.name + "' of signal '" + p_itype.name + "." + p_isignal.name + "'.");
if (p_itype.api_type == ClassDB::API_CORE) {
ERR_FAIL_COND_V_MSG(arg_type->api_type == ClassDB::API_EDITOR, ERR_BUG,
"Argument '" + iarg.name + "' of signal '" + p_itype.name + "." + p_isignal.name + "' has type '" +
arg_type->name + "' from the editor API. Core API cannot have dependencies on the editor API.");
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
// Add the current arguments to the signature
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
if (&iarg != &first) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
arguments_sig += ", ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
arguments_sig += arg_type->cs_type;
arguments_sig += " ";
arguments_sig += iarg.name;
}
// Generate signal
{
if (p_isignal.method_doc && p_isignal.method_doc->description.size()) {
String xml_summary = bbcode_to_xml(fix_doc_description(p_isignal.method_doc->description), &p_itype);
Vector<String> summary_lines = xml_summary.length() ? xml_summary.split("\n") : Vector<String>();
if (summary_lines.size()) {
p_output.append(MEMBER_BEGIN "/// <summary>\n");
for (int i = 0; i < summary_lines.size(); i++) {
p_output.append(INDENT2 "/// ");
p_output.append(summary_lines[i]);
p_output.append("\n");
}
p_output.append(INDENT2 "/// </summary>");
}
}
if (p_isignal.is_deprecated) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (p_isignal.deprecation_message.is_empty()) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
WARN_PRINT("An empty deprecation message is discouraged. Signal: '" + p_isignal.proxy_name + "'.");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append(MEMBER_BEGIN "[Obsolete(\"");
p_output.append(p_isignal.deprecation_message);
p_output.append("\")]");
}
String delegate_name = p_isignal.proxy_name;
delegate_name += "Handler"; // Delegate name is [SignalName]Handler
// Generate delegate
p_output.append(MEMBER_BEGIN "public delegate void ");
p_output.append(delegate_name);
p_output.append("(");
p_output.append(arguments_sig);
p_output.append(");\n");
// TODO:
// Could we assume the StringName instance of signal name will never be freed (it's stored in ClassDB) before the managed world is unloaded?
// If so, we could store the pointer we get from `data_unique_pointer()` instead of allocating StringName here.
// Cached signal name (StringName)
C#: Add initial implementation of source generator for script members This replaces the way we invoke methods and set/get properties. This first iteration rids us of runtime type checking in those cases, as it's now done at compile time. Later it will also stop needing the use of reflection. After that, we will only depend on reflection for generic Godot Array and Dictionary. We're stuck with reflection in generic collections for now as C# doesn't support generic/template specialization. This is only the initial implementation. Further iterations are coming, specially once we switch to the native extension system which completely changes the way members are accessed/invoked. For example, with the native extension system we will likely need to create `UnmanagedCallersOnly` invoke wrapper methods and return function pointers to the engine. Other kind of members, like event signals will be receiving the same treatment in the future.
2021-12-28 23:25:16 +01:00
p_output.append(MEMBER_BEGIN "// ReSharper disable once InconsistentNaming\n");
p_output.append(INDENT2 "[DebuggerBrowsable(DebuggerBrowsableState.Never)]" MEMBER_BEGIN
"private static readonly StringName " CS_STATIC_FIELD_SIGNAL_NAME_PREFIX);
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append(p_isignal.name);
p_output.append(" = \"");
p_output.append(p_isignal.name);
p_output.append("\";\n");
// Generate event
p_output.append(MEMBER_BEGIN "[Signal]" MEMBER_BEGIN "public ");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (p_itype.is_singleton) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append("static ");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append("event ");
p_output.append(delegate_name);
p_output.append(" ");
p_output.append(p_isignal.proxy_name);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("\n" OPEN_BLOCK_L2 INDENT3);
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (p_itype.is_singleton) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("add => " CS_PROPERTY_SINGLETON ".Connect(" CS_STATIC_FIELD_SIGNAL_NAME_PREFIX);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append("add => Connect(" CS_STATIC_FIELD_SIGNAL_NAME_PREFIX);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append(p_isignal.name);
p_output.append(", new Callable(value));\n");
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (p_itype.is_singleton) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(INDENT3 "remove => " CS_PROPERTY_SINGLETON ".Disconnect(" CS_STATIC_FIELD_SIGNAL_NAME_PREFIX);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
p_output.append(INDENT3 "remove => Disconnect(" CS_STATIC_FIELD_SIGNAL_NAME_PREFIX);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
p_output.append(p_isignal.name);
p_output.append(", new Callable(value));\n");
p_output.append(CLOSE_BLOCK_L2);
}
return OK;
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
Error BindingsGenerator::_generate_cs_native_calls(const InternalCall &p_icall, StringBuilder &r_output) {
bool ret_void = p_icall.return_type.cname == name_cache.type_void;
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *return_type = _get_type_or_null(p_icall.return_type);
ERR_FAIL_NULL_V(return_type, ERR_BUG); // Return type not found
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
StringBuilder c_func_sig;
StringBuilder c_in_statements;
StringBuilder c_args_var_content;
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
c_func_sig << "IntPtr " CS_PARAM_METHODBIND;
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (!p_icall.is_static) {
c_func_sig += ", IntPtr " CS_PARAM_INSTANCE;
Added mono module
2017-10-02 23:24:00 +02:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
// Get arguments information
int i = 0;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
for (const TypeReference &arg_type_ref : p_icall.argument_types) {
const TypeInterface *arg_type = _get_type_or_null(arg_type_ref);
ERR_FAIL_NULL_V(arg_type, ERR_BUG); // Return type not found
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
String c_param_name = "arg" + itos(i + 1);
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (p_icall.is_vararg) {
if (i < p_icall.get_arguments_count() - 1) {
C#/netcore: Add base desktop game export implementation This base implementation is still very barebones but it defines the path for how exporting will work (at least when embedding the .NET runtime). Many manual steps are still needed, which should be automatized in the future. For example, in addition to the API assemblies, now you also need to copy the GodotPlugins assembly to each game project.
2021-12-28 23:25:16 +01:00
String c_in_vararg = arg_type->c_in_vararg;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (arg_type->is_object_type) {
c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromGodotObject(%1);\n";
}
ERR_FAIL_COND_V_MSG(c_in_vararg.is_empty(), ERR_BUG,
"VarArg support not implemented for parameter type: " + arg_type->name);
c_in_statements
<< sformat(c_in_vararg, return_type->c_type, c_param_name,
String(), String(), String(), INDENT4)
<< INDENT4 C_LOCAL_PTRCALL_ARGS "[" << itos(i)
<< "] = new IntPtr(&" << c_param_name << "_in);\n";
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
} else {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (i > 0) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
c_args_var_content << ", ";
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
if (arg_type->c_in.size()) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
c_in_statements << sformat(arg_type->c_in, arg_type->c_type, c_param_name,
String(), String(), String(), INDENT3);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
c_args_var_content << sformat(arg_type->c_arg_in, c_param_name);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
c_func_sig << ", " << arg_type->c_type_in << " " << c_param_name;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
i++;
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
String icall_method = p_icall.name;
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Generate icall function
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << MEMBER_BEGIN "internal static unsafe " << (ret_void ? "void" : return_type->c_type_out) << " "
<< icall_method << "(" << c_func_sig.as_string() << ") " OPEN_BLOCK;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (!ret_void && (!p_icall.is_vararg || return_type->cname != name_cache.type_Variant)) {
String ptrcall_return_type;
String initialization;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (return_type->is_object_type) {
ptrcall_return_type = return_type->is_ref_counted ? "godot_ref" : return_type->c_type;
initialization = " = default";
} else {
ptrcall_return_type = return_type->c_type;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << INDENT3;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (return_type->is_ref_counted || return_type->c_type_is_disposable_struct) {
r_output << "using ";
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (initialization.is_empty()) {
initialization = " = default";
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else if (return_type->c_ret_needs_default_initialization) {
initialization = " = default";
}
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << ptrcall_return_type << " " C_LOCAL_RET << initialization << ";\n";
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (!p_icall.is_static) {
r_output << INDENT3 "if (" CS_PARAM_INSTANCE " == IntPtr.Zero)\n"
<< INDENT4 "throw new ArgumentNullException(nameof(" CS_PARAM_INSTANCE "));\n";
}
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
String argc_str = itos(p_icall.get_arguments_count());
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
auto generate_call_and_return_stmts = [&](const char *base_indent) {
if (p_icall.is_vararg) {
// MethodBind Call
r_output << base_indent;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// VarArg methods always return Variant, but there are some cases in which MethodInfo provides
// a specific return type. We trust this information is valid. We need a temporary local to keep
// the Variant alive until the method returns. Otherwise, if the returned Variant holds a RefPtr,
// it could be deleted too early. This is the case with GDScript.new() which returns OBJECT.
// Alternatively, we could just return Variant, but that would result in a worse API.
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
if (!ret_void) {
if (return_type->cname != name_cache.type_Variant) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << "using godot_variant " << C_LOCAL_VARARG_RET " = ";
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << "using godot_variant " << C_LOCAL_RET " = ";
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
}
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << C_CLASS_NATIVE_FUNCS ".godotsharp_method_bind_call("
<< CS_PARAM_METHODBIND ", " << (p_icall.is_static ? "IntPtr.Zero" : CS_PARAM_INSTANCE)
<< ", " << (p_icall.get_arguments_count() ? "(godot_variant**)" C_LOCAL_PTRCALL_ARGS : "null")
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
<< ", total_length, out _);\n";
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
Mono/C#: Fix bindings generator with void vararg methods Commit 4d727f1ee6b970298a7c1752ba19b49d7060c405 made it possible for vararg methods to return void. This broke the C# bindings generator which was assuming in one place that vararg methods always return Variant.
2020-01-02 18:02:45 +01:00
if (!ret_void) {
if (return_type->cname != name_cache.type_Variant) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (return_type->cname == name_cache.enum_Error) {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
r_output << base_indent << C_LOCAL_RET " = VariantUtils.ConvertToInt64(" C_LOCAL_VARARG_RET ");\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else {
// TODO: Use something similar to c_in_vararg (see usage above, with error if not implemented)
CRASH_NOW_MSG("Custom VarArg return type not implemented: " + return_type->name);
r_output << base_indent << C_LOCAL_RET " = " C_LOCAL_VARARG_RET ";\n";
}
Mono/C#: Fix bindings generator with void vararg methods Commit 4d727f1ee6b970298a7c1752ba19b49d7060c405 made it possible for vararg methods to return void. This broke the C# bindings generator which was assuming in one place that vararg methods always return Variant.
2020-01-02 18:02:45 +01:00
}
C# Bindings Generator: Fix vararg methods with custom return type
2019-01-18 00:41:41 +01:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// MethodBind PtrCall
r_output << base_indent << C_CLASS_NATIVE_FUNCS ".godotsharp_method_bind_ptrcall("
<< CS_PARAM_METHODBIND ", " << (p_icall.is_static ? "IntPtr.Zero" : CS_PARAM_INSTANCE)
<< ", " << (p_icall.get_arguments_count() ? C_LOCAL_PTRCALL_ARGS : "null")
<< ", " << (!ret_void ? "&" C_LOCAL_RET ");\n" : "null);\n");
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Return statement
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
if (!ret_void) {
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (return_type->c_out.is_empty()) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << base_indent << "return " C_LOCAL_RET ";\n";
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
} else {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << sformat(return_type->c_out, return_type->c_type_out, C_LOCAL_RET,
return_type->name, String(), String(), base_indent);
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
}
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
};
if (p_icall.get_arguments_count()) {
if (p_icall.is_vararg) {
String vararg_arg = "arg" + argc_str;
String real_argc_str = itos(p_icall.get_arguments_count() - 1); // Arguments count without vararg
p_icall.get_arguments_count();
r_output << INDENT3 "int vararg_length = " << vararg_arg << ".Length;\n"
<< INDENT3 "int total_length = " << real_argc_str << " + vararg_length;\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
r_output << INDENT3 "Span<godot_variant.movable> varargs_span = vararg_length <= VarArgsSpanThreshold ?\n"
<< INDENT4 "stackalloc godot_variant.movable[VarArgsSpanThreshold].Cleared() :\n"
<< INDENT4 "new godot_variant.movable[vararg_length];\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << INDENT3 "Span<IntPtr> " C_LOCAL_PTRCALL_ARGS "_span = total_length <= VarArgsSpanThreshold ?\n"
<< INDENT4 "stackalloc IntPtr[VarArgsSpanThreshold] :\n"
<< INDENT4 "new IntPtr[total_length];\n";
r_output << INDENT3 "using var variantSpanDisposer = new VariantSpanDisposer(varargs_span);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
r_output << INDENT3 "fixed (godot_variant* varargs = &MemoryMarshal.GetReference(varargs_span).DangerousSelfRef)\n"
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
<< INDENT3 "fixed (IntPtr* " C_LOCAL_PTRCALL_ARGS " = "
"&MemoryMarshal.GetReference(" C_LOCAL_PTRCALL_ARGS "_span))\n"
<< OPEN_BLOCK_L3;
r_output << c_in_statements.as_string();
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << INDENT4 "for (int i = 0; i < vararg_length; i++) " OPEN_BLOCK
<< INDENT5 "varargs[i] = " C_METHOD_MANAGED_TO_VARIANT "(" << vararg_arg << "[i]);\n"
<< INDENT5 C_LOCAL_PTRCALL_ARGS "[" << real_argc_str << " + i] = new IntPtr(&varargs[i]);\n"
<< CLOSE_BLOCK_L4;
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
generate_call_and_return_stmts(INDENT4);
r_output << CLOSE_BLOCK_L3;
} else {
r_output << c_in_statements.as_string();
r_output << INDENT3 "void** " C_LOCAL_PTRCALL_ARGS " = stackalloc void*["
<< argc_str << "] { " << c_args_var_content.as_string() << " };\n";
generate_call_and_return_stmts(INDENT3);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else {
generate_call_and_return_stmts(INDENT3);
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_output << CLOSE_BLOCK_L2;
return OK;
}
Error BindingsGenerator::_save_file(const String &p_path, const StringBuilder &p_content) {
Ref<FileAccess> file = FileAccess::open(p_path, FileAccess::WRITE);
ERR_FAIL_COND_V_MSG(file.is_null(), ERR_FILE_CANT_WRITE, "Cannot open file: '" + p_path + "'.");
file->store_string(p_content.as_string());
BindingsGenerator cleanup and improved error messages If there is an error generating a property or a method, the error message will include the member and class names.
2017-10-29 02:37:13 +01:00
return OK;
}
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
const BindingsGenerator::TypeInterface *BindingsGenerator::_get_type_or_null(const TypeReference &p_typeref) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, TypeInterface>::ConstIterator builtin_type_match = builtin_types.find(p_typeref.cname);
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (builtin_type_match) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
return &builtin_type_match->value;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, TypeInterface>::ConstIterator obj_type_match = obj_types.find(p_typeref.cname);
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (obj_type_match) {
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
return &obj_type_match->value;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
if (p_typeref.is_enum) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, TypeInterface>::ConstIterator enum_match = enum_types.find(p_typeref.cname);
Added mono module
2017-10-02 23:24:00 +02:00
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (enum_match) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
return &enum_match->value;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
// Enum not found. Most likely because none of its constants were bound, so it's empty. That's fine. Use int instead.
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, TypeInterface>::ConstIterator int_match = builtin_types.find(name_cache.type_int);
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
ERR_FAIL_NULL_V(int_match, nullptr);
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
return &int_match->value;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
return nullptr;
Added mono module
2017-10-02 23:24:00 +02:00
}
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
const String BindingsGenerator::_get_generic_type_parameters(const TypeInterface &p_itype, const List<TypeReference> &p_generic_type_parameters) {
if (p_generic_type_parameters.is_empty()) {
return "";
}
ERR_FAIL_COND_V_MSG(p_itype.type_parameter_count != p_generic_type_parameters.size(), "",
"Generic type parameter count mismatch for type '" + p_itype.name + "'." +
" Found " + itos(p_generic_type_parameters.size()) + ", but requires " +
itos(p_itype.type_parameter_count) + ".");
int i = 0;
String params = "<";
for (const TypeReference &param_type : p_generic_type_parameters) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface *param_itype = _get_type_or_null(param_type);
ERR_FAIL_NULL_V(param_itype, "");
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
ERR_FAIL_COND_V_MSG(param_itype->is_singleton, "",
"Generic type parameter is a singleton: '" + param_itype->name + "'.");
if (p_itype.api_type == ClassDB::API_CORE) {
ERR_FAIL_COND_V_MSG(param_itype->api_type == ClassDB::API_EDITOR, "",
"Generic type parameter '" + param_itype->name + "' has type from the editor API." +
" Core API cannot have dependencies on the editor API.");
}
params += param_itype->cs_type;
if (i < p_generic_type_parameters.size() - 1) {
params += ", ";
}
i++;
}
params += ">";
return params;
}
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
StringName BindingsGenerator::_get_int_type_name_from_meta(GodotTypeInfo::Metadata p_meta) {
switch (p_meta) {
case GodotTypeInfo::METADATA_INT_IS_INT8:
return "sbyte";
break;
case GodotTypeInfo::METADATA_INT_IS_INT16:
return "short";
break;
case GodotTypeInfo::METADATA_INT_IS_INT32:
return "int";
break;
case GodotTypeInfo::METADATA_INT_IS_INT64:
return "long";
break;
case GodotTypeInfo::METADATA_INT_IS_UINT8:
return "byte";
break;
case GodotTypeInfo::METADATA_INT_IS_UINT16:
return "ushort";
break;
case GodotTypeInfo::METADATA_INT_IS_UINT32:
return "uint";
break;
case GodotTypeInfo::METADATA_INT_IS_UINT64:
return "ulong";
break;
default:
// Assume INT32
return "int";
}
}
StringName BindingsGenerator::_get_float_type_name_from_meta(GodotTypeInfo::Metadata p_meta) {
switch (p_meta) {
case GodotTypeInfo::METADATA_REAL_IS_FLOAT:
return "float";
break;
case GodotTypeInfo::METADATA_REAL_IS_DOUBLE:
return "double";
break;
default:
// Assume real_t (float or double depending of REAL_T_IS_DOUBLE)
#ifdef REAL_T_IS_DOUBLE
return "double";
#else
return "float";
#endif
}
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
bool BindingsGenerator::_arg_default_value_is_assignable_to_type(const Variant &p_val, const TypeInterface &p_arg_type) {
if (p_arg_type.name == name_cache.type_Variant) {
// Variant can take anything
return true;
}
switch (p_val.get_type()) {
case Variant::NIL:
return p_arg_type.is_object_type ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
name_cache.is_nullable_type(p_arg_type.name);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::BOOL:
return p_arg_type.name == name_cache.type_bool;
case Variant::INT:
return p_arg_type.name == name_cache.type_sbyte ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == name_cache.type_short ||
p_arg_type.name == name_cache.type_int ||
p_arg_type.name == name_cache.type_byte ||
p_arg_type.name == name_cache.type_ushort ||
p_arg_type.name == name_cache.type_uint ||
p_arg_type.name == name_cache.type_long ||
p_arg_type.name == name_cache.type_ulong ||
p_arg_type.name == name_cache.type_float ||
p_arg_type.name == name_cache.type_double ||
p_arg_type.is_enum;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::FLOAT:
return p_arg_type.name == name_cache.type_float ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == name_cache.type_double;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::STRING:
case Variant::STRING_NAME:
return p_arg_type.name == name_cache.type_String ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == name_cache.type_StringName ||
p_arg_type.name == name_cache.type_NodePath;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::NODE_PATH:
return p_arg_type.name == name_cache.type_NodePath;
case Variant::TRANSFORM2D:
Rename Variant TRANSFORM to TRANSFORM3D Also _transform to _transform3d
2021-04-28 09:36:08 +02:00
case Variant::TRANSFORM3D:
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::BASIS:
Rename Quat to Quaternion
2021-01-20 08:02:02 +01:00
case Variant::QUATERNION:
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::PLANE:
case Variant::AABB:
case Variant::COLOR:
case Variant::VECTOR2:
case Variant::RECT2:
case Variant::VECTOR3:
Variant: Rename Type::_RID to Type::RID The underscore prefix was used to avoid the conflict between the `RID` class name and the matching enum value in `Variant::Type`. This can be fixed differently by prefixing uses of the `RID` class in `Variant` with the scope resolution operator, as done already for `AABB`.
2020-11-09 14:53:05 +01:00
case Variant::RID:
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::PACKED_BYTE_ARRAY:
case Variant::PACKED_INT32_ARRAY:
case Variant::PACKED_INT64_ARRAY:
case Variant::PACKED_FLOAT32_ARRAY:
case Variant::PACKED_FLOAT64_ARRAY:
case Variant::PACKED_STRING_ARRAY:
case Variant::PACKED_VECTOR2_ARRAY:
case Variant::PACKED_VECTOR3_ARRAY:
case Variant::PACKED_COLOR_ARRAY:
case Variant::CALLABLE:
case Variant::SIGNAL:
return p_arg_type.name == Variant::get_type_name(p_val.get_type());
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
case Variant::ARRAY:
return p_arg_type.name == Variant::get_type_name(p_val.get_type()) || p_arg_type.cname == name_cache.type_Array_generic;
case Variant::DICTIONARY:
return p_arg_type.name == Variant::get_type_name(p_val.get_type()) || p_arg_type.cname == name_cache.type_Dictionary_generic;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::OBJECT:
return p_arg_type.is_object_type;
case Variant::VECTOR2I:
return p_arg_type.name == name_cache.type_Vector2 ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == Variant::get_type_name(p_val.get_type());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::RECT2I:
return p_arg_type.name == name_cache.type_Rect2 ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == Variant::get_type_name(p_val.get_type());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
case Variant::VECTOR3I:
return p_arg_type.name == name_cache.type_Vector3 ||
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
p_arg_type.name == Variant::get_type_name(p_val.get_type());
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
default:
CRASH_NOW_MSG("Unexpected Variant type: " + itos(p_val.get_type()));
break;
}
return false;
}
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
bool BindingsGenerator::_populate_object_type_interfaces() {
Added mono module
2017-10-02 23:24:00 +02:00
obj_types.clear();
List<StringName> class_list;
ClassDB::get_class_list(&class_list);
class_list.sort_custom<StringName::AlphCompare>();
while (class_list.size()) {
StringName type_cname = class_list.front()->get();
ClassDB::APIType api_type = ClassDB::get_api_type(type_cname);
if (api_type == ClassDB::API_NONE) {
class_list.pop_front();
continue;
}
Ignore PhysicsServer3DExtension class in C# PhysicsServer3DExtension inherits from PhysicsServer3D which is a singleton class, since singleton classes are generated as static in C# it would generate invalid C# so for now we'll be ignoring PhysicsServer3DExtension.
2022-03-18 17:28:48 +01:00
if (ignored_types.has(type_cname)) {
_log("Ignoring type '%s' because it's in the list of ignored types\n", String(type_cname).utf8().get_data());
class_list.pop_front();
continue;
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (!ClassDB::is_class_exposed(type_cname)) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
_log("Ignoring type '%s' because it's not exposed\n", String(type_cname).utf8().get_data());
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
class_list.pop_front();
continue;
}
Make C# bindings generator ignore disabled classes
2018-07-18 21:15:41 +02:00
if (!ClassDB::is_class_enabled(type_cname)) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
_log("Ignoring type '%s' because it's not enabled\n", String(type_cname).utf8().get_data());
Make C# bindings generator ignore disabled classes
2018-07-18 21:15:41 +02:00
class_list.pop_front();
continue;
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
ClassDB::ClassInfo *class_info = ClassDB::classes.getptr(type_cname);
Added mono module
2017-10-02 23:24:00 +02:00
TypeInterface itype = TypeInterface::create_object_type(type_cname, api_type);
itype.base_name = ClassDB::get_parent_class(type_cname);
Move singleton management from ProjectSettings to Engine
2017-11-13 21:46:57 +01:00
itype.is_singleton = Engine::get_singleton()->has_singleton(itype.proxy_name);
Fix C# bindings detection of abstract classes ClassDB::can_instance was changed recently breaking our code, as the editor is not yet initialized. Check ClassInfo::creation_func directly.
2019-07-08 15:13:57 +02:00
itype.is_instantiable = class_info->creation_func && !itype.is_singleton;
Rename Reference to RefCounted
2021-06-04 18:03:15 +02:00
itype.is_ref_counted = ClassDB::is_parent_class(type_cname, name_cache.type_RefCounted);
itype.memory_own = itype.is_ref_counted;
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_out = "%5return ";
Added mono module
2017-10-02 23:24:00 +02:00
itype.c_out += C_METHOD_UNMANAGED_GET_MANAGED;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_out += itype.is_ref_counted ? "(%1.Reference);\n" : "(%1);\n";
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.cs_type = itype.proxy_name;
if (itype.is_singleton) {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "Object." CS_STATIC_METHOD_GETINSTANCE "(" CS_PROPERTY_SINGLETON ")";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
} else {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "Object." CS_STATIC_METHOD_GETINSTANCE "(%0)";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.cs_out = "%5return (%2)%0(%1);";
itype.c_arg_in = "(void*)%s";
itype.c_type = "IntPtr";
Added mono module
2017-10-02 23:24:00 +02:00
itype.c_type_in = itype.c_type;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_out = "Object";
Added mono module
2017-10-02 23:24:00 +02:00
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
// Populate properties
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
List<PropertyInfo> property_list;
ClassDB::get_property_list(type_cname, &property_list, true);
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, StringName> accessor_methods;
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
Use C++ iterators for Lists in many situations
2021-07-16 05:45:57 +02:00
for (const PropertyInfo &property : property_list) {
Fix properties arrays in C# bindings generator
2021-09-08 12:51:45 +02:00
if (property.usage & PROPERTY_USAGE_GROUP || property.usage & PROPERTY_USAGE_SUBGROUP || property.usage & PROPERTY_USAGE_CATEGORY || (property.type == Variant::NIL && property.usage & PROPERTY_USAGE_ARRAY)) {
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
C#/Mono: Check assembly version when loading Not sure if we should check revision too, but this is good enough for what we want. This will be needed to load the correct Microsoft.Build when we switch to the nuget version.
2020-05-09 20:54:07 +02:00
if (property.name.find("/") >= 0) {
// Ignore properties with '/' (slash) in the name. These are only meant for use in the inspector.
continue;
}
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
PropertyInterface iprop;
iprop.cname = property.name;
iprop.setter = ClassDB::get_property_setter(type_cname, iprop.cname);
iprop.getter = ClassDB::get_property_getter(type_cname, iprop.cname);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (iprop.setter != StringName()) {
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
accessor_methods[iprop.setter] = iprop.cname;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
if (iprop.getter != StringName()) {
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
accessor_methods[iprop.getter] = iprop.cname;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
bool valid = false;
iprop.index = ClassDB::get_property_index(type_cname, iprop.cname, &valid);
C#/Mono: Check assembly version when loading Not sure if we should check revision too, but this is good enough for what we want. This will be needed to load the correct Microsoft.Build when we switch to the nuget version.
2020-05-09 20:54:07 +02:00
ERR_FAIL_COND_V_MSG(!valid, false, "Invalid property: '" + itype.name + "." + String(iprop.cname) + "'.");
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
C#: Bindings generator now translates BBCode docs to XML comments
2019-03-18 21:59:35 +01:00
iprop.proxy_name = escape_csharp_keyword(snake_to_pascal_case(iprop.cname));
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
// Prevent the property and its enclosing type from sharing the same name
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
if (iprop.proxy_name == itype.proxy_name) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
_log("Name of property '%s' is ambiguous with the name of its enclosing class '%s'. Renaming property to '%s_'\n",
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
iprop.proxy_name.utf8().get_data(), itype.proxy_name.utf8().get_data(), iprop.proxy_name.utf8().get_data());
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
iprop.proxy_name += "_";
}
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
iprop.prop_doc = nullptr;
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
for (int i = 0; i < itype.class_doc->properties.size(); i++) {
const DocData::PropertyDoc &prop_doc = itype.class_doc->properties[i];
if (prop_doc.name == iprop.cname) {
iprop.prop_doc = &prop_doc;
break;
}
}
itype.properties.push_back(iprop);
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Populate methods
Added mono module
2017-10-02 23:24:00 +02:00
List<MethodInfo> virtual_method_list;
ClassDB::get_virtual_methods(type_cname, &virtual_method_list, true);
List<MethodInfo> method_list;
ClassDB::get_method_list(type_cname, &method_list, true);
method_list.sort();
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const MethodInfo &method_info : method_list) {
Added mono module
2017-10-02 23:24:00 +02:00
int argc = method_info.arguments.size();
Rename empty() to is_empty()
2020-12-15 13:04:21 +01:00
if (method_info.name.is_empty()) {
Added mono module
2017-10-02 23:24:00 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
String cname = method_info.name;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (blacklisted_methods.find(itype.cname) && blacklisted_methods[itype.cname].find(cname)) {
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
continue;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
Added mono module
2017-10-02 23:24:00 +02:00
MethodInterface imethod;
imethod.name = method_info.name;
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
imethod.cname = cname;
Added mono module
2017-10-02 23:24:00 +02:00
Support static methods in C# bindings generator
2022-03-21 01:25:50 +01:00
if (method_info.flags & METHOD_FLAG_STATIC) {
imethod.is_static = true;
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (method_info.flags & METHOD_FLAG_VIRTUAL) {
Added mono module
2017-10-02 23:24:00 +02:00
imethod.is_virtual = true;
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
itype.has_virtual_methods = true;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
PropertyInfo return_info = method_info.return_val;
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
MethodBind *m = imethod.is_virtual ? nullptr : ClassDB::get_method(type_cname, method_info.name);
Added mono module
2017-10-02 23:24:00 +02:00
imethod.is_vararg = m && m->is_vararg();
if (!m && !imethod.is_virtual) {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V_MSG(!virtual_method_list.find(method_info), false,
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
"Missing MethodBind for non-virtual method: '" + itype.name + "." + imethod.name + "'.");
// A virtual method without the virtual flag. This is a special case.
// There is no method bind, so let's fallback to Godot's object.Call(string, params)
imethod.requires_object_call = true;
// The method Object.free is registered as a virtual method, but without the virtual flag.
// This is because this method is not supposed to be overridden, but called.
// We assume the return type is void.
imethod.return_type.cname = name_cache.type_void;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
// Actually, more methods like this may be added in the future, which could return
// something different. Let's put this check to notify us if that ever happens.
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
if (itype.cname != name_cache.type_Object || imethod.name != "free") {
Remove duplicate WARN_PRINT macro.
2019-11-07 09:44:15 +01:00
WARN_PRINT("Notification: New unexpected virtual non-overridable method found."
" We only expected Object.free, but found '" +
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
itype.name + "." + imethod.name + "'.");
Added mono module
2017-10-02 23:24:00 +02:00
}
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
} else if (return_info.type == Variant::INT && return_info.usage & (PROPERTY_USAGE_CLASS_IS_ENUM | PROPERTY_USAGE_CLASS_IS_BITFIELD)) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
imethod.return_type.cname = return_info.class_name;
imethod.return_type.is_enum = true;
Added mono module
2017-10-02 23:24:00 +02:00
} else if (return_info.class_name != StringName()) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
imethod.return_type.cname = return_info.class_name;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
bool bad_reference_hint = !imethod.is_virtual && return_info.hint != PROPERTY_HINT_RESOURCE_TYPE &&
clang-format: Disable alignment of operands, too unreliable Sets `AlignOperands` to `DontAlign`. `clang-format` developers seem to mostly care about space-based indentation and every other version of clang-format breaks the bad mismatch of tabs and spaces that it seems to use for operand alignment. So it's better without, so that it respects our two-tabs `ContinuationIndentWidth`.
2021-10-28 15:19:35 +02:00
ClassDB::is_parent_class(return_info.class_name, name_cache.type_RefCounted);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(bad_reference_hint, false,
String() + "Return type is reference but hint is not '" _STR(PROPERTY_HINT_RESOURCE_TYPE) "'." +
" Are you returning a reference type by pointer? Method: '" + itype.name + "." + imethod.name + "'.");
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
} else if (return_info.type == Variant::ARRAY && return_info.hint == PROPERTY_HINT_ARRAY_TYPE) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
imethod.return_type.cname = Variant::get_type_name(return_info.type) + "_@generic";
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
imethod.return_type.generic_type_parameters.push_back(TypeReference(return_info.hint_string));
Added mono module
2017-10-02 23:24:00 +02:00
} else if (return_info.hint == PROPERTY_HINT_RESOURCE_TYPE) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
imethod.return_type.cname = return_info.hint_string;
Added mono module
2017-10-02 23:24:00 +02:00
} else if (return_info.type == Variant::NIL && return_info.usage & PROPERTY_USAGE_NIL_IS_VARIANT) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
imethod.return_type.cname = name_cache.type_Variant;
Added mono module
2017-10-02 23:24:00 +02:00
} else if (return_info.type == Variant::NIL) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
imethod.return_type.cname = name_cache.type_void;
Added mono module
2017-10-02 23:24:00 +02:00
} else {
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
if (return_info.type == Variant::INT) {
imethod.return_type.cname = _get_int_type_name_from_meta(m ? m->get_argument_meta(-1) : GodotTypeInfo::METADATA_NONE);
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
} else if (return_info.type == Variant::FLOAT) {
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
imethod.return_type.cname = _get_float_type_name_from_meta(m ? m->get_argument_meta(-1) : GodotTypeInfo::METADATA_NONE);
} else {
imethod.return_type.cname = Variant::get_type_name(return_info.type);
}
Added mono module
2017-10-02 23:24:00 +02:00
}
for (int i = 0; i < argc; i++) {
PropertyInfo arginfo = method_info.arguments[i];
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
String orig_arg_name = arginfo.name;
Added mono module
2017-10-02 23:24:00 +02:00
ArgumentInterface iarg;
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
iarg.name = orig_arg_name;
Added mono module
2017-10-02 23:24:00 +02:00
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
if (arginfo.type == Variant::INT && arginfo.usage & (PROPERTY_USAGE_CLASS_IS_ENUM | PROPERTY_USAGE_CLASS_IS_BITFIELD)) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
iarg.type.cname = arginfo.class_name;
iarg.type.is_enum = true;
Added mono module
2017-10-02 23:24:00 +02:00
} else if (arginfo.class_name != StringName()) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
iarg.type.cname = arginfo.class_name;
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
} else if (arginfo.type == Variant::ARRAY && arginfo.hint == PROPERTY_HINT_ARRAY_TYPE) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
iarg.type.cname = Variant::get_type_name(arginfo.type) + "_@generic";
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
iarg.type.generic_type_parameters.push_back(TypeReference(arginfo.hint_string));
Added mono module
2017-10-02 23:24:00 +02:00
} else if (arginfo.hint == PROPERTY_HINT_RESOURCE_TYPE) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
iarg.type.cname = arginfo.hint_string;
Added mono module
2017-10-02 23:24:00 +02:00
} else if (arginfo.type == Variant::NIL) {
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
iarg.type.cname = name_cache.type_Variant;
Added mono module
2017-10-02 23:24:00 +02:00
} else {
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
if (arginfo.type == Variant::INT) {
iarg.type.cname = _get_int_type_name_from_meta(m ? m->get_argument_meta(i) : GodotTypeInfo::METADATA_NONE);
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
} else if (arginfo.type == Variant::FLOAT) {
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
iarg.type.cname = _get_float_type_name_from_meta(m ? m->get_argument_meta(i) : GodotTypeInfo::METADATA_NONE);
} else {
iarg.type.cname = Variant::get_type_name(arginfo.type);
}
Added mono module
2017-10-02 23:24:00 +02:00
}
iarg.name = escape_csharp_keyword(snake_to_camel_case(iarg.name));
if (m && m->has_default_argument(i)) {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
bool defval_ok = _arg_default_value_from_variant(m->get_default_argument(i), iarg);
ERR_FAIL_COND_V_MSG(!defval_ok, false,
"Cannot determine default value for argument '" + orig_arg_name + "' of method '" + itype.name + "." + imethod.name + "'.");
Added mono module
2017-10-02 23:24:00 +02:00
}
imethod.add_argument(iarg);
}
if (imethod.is_vararg) {
ArgumentInterface ivararg;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
ivararg.type.cname = name_cache.type_VarArg;
Added mono module
2017-10-02 23:24:00 +02:00
ivararg.name = "@args";
imethod.add_argument(ivararg);
}
imethod.proxy_name = escape_csharp_keyword(snake_to_pascal_case(imethod.name));
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
// Prevent the method and its enclosing type from sharing the same name
Added mono module
2017-10-02 23:24:00 +02:00
if (imethod.proxy_name == itype.proxy_name) {
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
_log("Name of method '%s' is ambiguous with the name of its enclosing class '%s'. Renaming method to '%s_'\n",
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
imethod.proxy_name.utf8().get_data(), itype.proxy_name.utf8().get_data(), imethod.proxy_name.utf8().get_data());
Added mono module
2017-10-02 23:24:00 +02:00
imethod.proxy_name += "_";
}
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<StringName, StringName>::Iterator accessor = accessor_methods.find(imethod.cname);
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
if (accessor) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
const PropertyInterface *accessor_property = itype.find_property_by_name(accessor->value);
C#: Mark generated property accessor methods as Obsolete - Methods that act as accessors for properties in the same class (like `GetPosition` and `SetPosition` are for `Position`) are now marked as obsolete. They will be made private in the future.
2019-04-25 17:11:01 +02:00
// We only deprecate an accessor method if it's in the same class as the property. It's easier this way, but also
// we don't know if an accessor method in a different class could have other purposes, so better leave those untouched.
imethod.is_deprecated = true;
imethod.deprecation_message = imethod.proxy_name + " is deprecated. Use the " + accessor_property->proxy_name + " property instead.";
}
Added mono module
2017-10-02 23:24:00 +02:00
if (itype.class_doc) {
for (int i = 0; i < itype.class_doc->methods.size(); i++) {
if (itype.class_doc->methods[i].name == imethod.name) {
imethod.method_doc = &itype.class_doc->methods[i];
break;
}
}
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
ERR_FAIL_COND_V_MSG(itype.find_property_by_name(imethod.cname), false,
"Method name conflicts with property: '" + itype.name + "." + imethod.name + "'.");
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
// Methods starting with an underscore are ignored unless they're used as a property setter or getter
Added mono module
2017-10-02 23:24:00 +02:00
if (!imethod.is_virtual && imethod.name[0] == '_') {
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const PropertyInterface &iprop : itype.properties) {
Mono: Bindings no longer relie on DocData for accessors
2017-12-29 02:18:46 +01:00
if (iprop.setter == imethod.name || iprop.getter == imethod.name) {
Added mono module
2017-10-02 23:24:00 +02:00
imethod.is_internal = true;
itype.methods.push_back(imethod);
break;
}
}
} else {
itype.methods.push_back(imethod);
}
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
// Populate signals
const HashMap<StringName, MethodInfo> &signal_map = class_info->signal_map;
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
for (const KeyValue<StringName, MethodInfo> &E : signal_map) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
SignalInterface isignal;
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
const MethodInfo &method_info = E.value;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
isignal.name = method_info.name;
isignal.cname = method_info.name;
int argc = method_info.arguments.size();
for (int i = 0; i < argc; i++) {
PropertyInfo arginfo = method_info.arguments[i];
String orig_arg_name = arginfo.name;
ArgumentInterface iarg;
iarg.name = orig_arg_name;
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
if (arginfo.type == Variant::INT && arginfo.usage & (PROPERTY_USAGE_CLASS_IS_ENUM | PROPERTY_USAGE_CLASS_IS_BITFIELD)) {
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
iarg.type.cname = arginfo.class_name;
iarg.type.is_enum = true;
} else if (arginfo.class_name != StringName()) {
iarg.type.cname = arginfo.class_name;
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
} else if (arginfo.type == Variant::ARRAY && arginfo.hint == PROPERTY_HINT_ARRAY_TYPE) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
iarg.type.cname = Variant::get_type_name(arginfo.type) + "_@generic";
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
iarg.type.generic_type_parameters.push_back(TypeReference(arginfo.hint_string));
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
} else if (arginfo.hint == PROPERTY_HINT_RESOURCE_TYPE) {
iarg.type.cname = arginfo.hint_string;
} else if (arginfo.type == Variant::NIL) {
iarg.type.cname = name_cache.type_Variant;
} else {
if (arginfo.type == Variant::INT) {
iarg.type.cname = _get_int_type_name_from_meta(GodotTypeInfo::METADATA_NONE);
} else if (arginfo.type == Variant::FLOAT) {
iarg.type.cname = _get_float_type_name_from_meta(GodotTypeInfo::METADATA_NONE);
} else {
iarg.type.cname = Variant::get_type_name(arginfo.type);
}
}
iarg.name = escape_csharp_keyword(snake_to_camel_case(iarg.name));
isignal.add_argument(iarg);
}
isignal.proxy_name = escape_csharp_keyword(snake_to_pascal_case(isignal.name));
// Prevent the signal and its enclosing type from sharing the same name
if (isignal.proxy_name == itype.proxy_name) {
_log("Name of signal '%s' is ambiguous with the name of its enclosing class '%s'. Renaming signal to '%s_'\n",
isignal.proxy_name.utf8().get_data(), itype.proxy_name.utf8().get_data(), isignal.proxy_name.utf8().get_data());
isignal.proxy_name += "_";
}
if (itype.find_property_by_proxy_name(isignal.proxy_name) || itype.find_method_by_proxy_name(isignal.proxy_name)) {
// ClassDB allows signal names that conflict with method or property names.
// While registering a signal with a conflicting name is considered wrong,
// it may still happen and it may take some time until someone fixes the name.
// We can't allow the bindings to be in a broken state while we wait for a fix;
// that's why we must handle this possibility by renaming the signal.
isignal.proxy_name += "Signal";
}
if (itype.class_doc) {
for (int i = 0; i < itype.class_doc->signals.size(); i++) {
const DocData::MethodDoc &signal_doc = itype.class_doc->signals[i];
if (signal_doc.name == isignal.name) {
isignal.method_doc = &signal_doc;
break;
}
}
}
itype.signals_.push_back(isignal);
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// Populate enums and constants
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
List<String> constants;
ClassDB::get_integer_constant_list(type_cname, &constants, true);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
const HashMap<StringName, ClassDB::ClassInfo::EnumInfo> &enum_map = class_info->enum_map;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
for (const KeyValue<StringName, ClassDB::ClassInfo::EnumInfo> &E : enum_map) {
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
StringName enum_proxy_cname = E.key;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
String enum_proxy_name = enum_proxy_cname.operator String();
if (itype.find_property_by_proxy_name(enum_proxy_cname)) {
// We have several conflicts between enums and PascalCase properties,
// so we append 'Enum' to the enum name in those cases.
enum_proxy_name += "Enum";
enum_proxy_cname = StringName(enum_proxy_name);
}
EnumInterface ienum(enum_proxy_cname);
Add C# support for bitfield enums (flags)
2022-06-24 20:25:30 +02:00
ienum.is_flags = E.value.is_bitfield;
Implement a BitField hint Allows to specify the binder that an enum must be treated as a bitfield.
2022-06-24 11:16:37 +02:00
const List<StringName> &enum_constants = E.value.constants;
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const StringName &constant_cname : enum_constants) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
String constant_name = constant_cname.operator String();
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
int64_t *value = class_info->constant_map.getptr(constant_cname);
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_NULL_V(value, false);
Use StringBuilder in C# bindings generator - Also fixed generation of empty summary comments when no comment should have been generated.
2019-04-19 01:10:08 +02:00
constants.erase(constant_name);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
ConstantInterface iconstant(constant_name, snake_to_pascal_case(constant_name, true), *value);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
iconstant.const_doc = nullptr;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
for (int i = 0; i < itype.class_doc->constants.size(); i++) {
const DocData::ConstantDoc &const_doc = itype.class_doc->constants[i];
if (const_doc.name == iconstant.name) {
iconstant.const_doc = &const_doc;
break;
}
}
ienum.constants.push_back(iconstant);
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
int prefix_length = _determine_enum_prefix(ienum);
_apply_prefix_to_enum_constants(ienum, prefix_length);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.enums.push_back(ienum);
TypeInterface enum_itype;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
enum_itype.is_enum = true;
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
enum_itype.name = itype.name + "." + String(E.key);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
enum_itype.cname = StringName(enum_itype.name);
enum_itype.proxy_name = itype.proxy_name + "." + enum_proxy_name;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
TypeInterface::postsetup_enum_type(enum_itype);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
enum_types.insert(enum_itype.cname, enum_itype);
}
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const String &constant_name : constants) {
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
int64_t *value = class_info->constant_map.getptr(StringName(constant_name));
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_NULL_V(value, false);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
ConstantInterface iconstant(constant_name, snake_to_pascal_case(constant_name, true), *value);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
iconstant.const_doc = nullptr;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
for (int i = 0; i < itype.class_doc->constants.size(); i++) {
const DocData::ConstantDoc &const_doc = itype.class_doc->constants[i];
if (const_doc.name == iconstant.name) {
iconstant.const_doc = &const_doc;
break;
}
}
itype.constants.push_back(iconstant);
}
obj_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
class_list.pop_front();
}
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
return true;
Added mono module
2017-10-02 23:24:00 +02:00
}
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
bool BindingsGenerator::_arg_default_value_from_variant(const Variant &p_val, ArgumentInterface &r_iarg) {
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
r_iarg.def_param_value = p_val;
r_iarg.default_argument = p_val.operator String();
Added mono module
2017-10-02 23:24:00 +02:00
switch (p_val.get_type()) {
case Variant::NIL:
Mono: Fix -Wduplicated-branches warning
2019-06-15 17:34:07 +02:00
// Either Object type or Variant
r_iarg.default_argument = "null";
Added mono module
2017-10-02 23:24:00 +02:00
break;
// Atomic types
case Variant::BOOL:
r_iarg.default_argument = bool(p_val) ? "true" : "false";
break;
case Variant::INT:
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
if (r_iarg.type.cname != name_cache.type_int) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
r_iarg.default_argument = "(%s)" + r_iarg.default_argument;
}
break;
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
case Variant::FLOAT:
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
if (r_iarg.type.cname == name_cache.type_float) {
r_iarg.default_argument += "f";
}
Added mono module
2017-10-02 23:24:00 +02:00
break;
case Variant::STRING:
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
case Variant::STRING_NAME:
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::NODE_PATH:
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
if (r_iarg.type.cname == name_cache.type_StringName || r_iarg.type.cname == name_cache.type_NodePath) {
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
if (r_iarg.default_argument.length() > 0) {
r_iarg.default_argument = "(%s)\"" + r_iarg.default_argument + "\"";
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_REF;
} else {
// No need for a special `in` statement to change `null` to `""`. Marshaling takes care of this already.
r_iarg.default_argument = "null";
}
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
} else {
CRASH_COND(r_iarg.type.cname != name_cache.type_String);
r_iarg.default_argument = "\"" + r_iarg.default_argument + "\"";
}
Added mono module
2017-10-02 23:24:00 +02:00
break;
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
case Variant::PLANE: {
Plane plane = p_val.operator Plane();
Reformat structure string operators The order of numbers is not changed except for Transform2D. All logic is done inside of their structures (and not in Variant). For the number of decimals printed, they now use String::num_real which works best with real_t, except for Color which is fixed at 4 decimals (this is a reliable number of float digits when converting from 16-bpc so it seems like a good choice)
2021-02-25 15:54:50 +01:00
r_iarg.default_argument = "new Plane(new Vector3" + plane.normal.operator String() + ", " + rtos(plane.d) + ")";
Added mono module
2017-10-02 23:24:00 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
} break;
case Variant::AABB: {
AABB aabb = p_val.operator ::AABB();
Fix a typo in C# bindings generator for default value types
2021-06-18 07:13:00 +02:00
r_iarg.default_argument = "new AABB(new Vector3" + aabb.position.operator String() + ", new Vector3" + aabb.size.operator String() + ")";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
case Variant::RECT2: {
Rect2 rect = p_val.operator Rect2();
Fix a typo in C# bindings generator for default value types
2021-06-18 07:13:00 +02:00
r_iarg.default_argument = "new Rect2(new Vector2" + rect.position.operator String() + ", new Vector2" + rect.size.operator String() + ")";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
case Variant::RECT2I: {
Rect2i rect = p_val.operator Rect2i();
Fix a typo in C# bindings generator for default value types
2021-06-18 07:13:00 +02:00
r_iarg.default_argument = "new Rect2i(new Vector2i" + rect.position.operator String() + ", new Vector2i" + rect.size.operator String() + ")";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::COLOR:
case Variant::VECTOR2:
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
case Variant::VECTOR2I:
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::VECTOR3:
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
case Variant::VECTOR3I:
Added mono module
2017-10-02 23:24:00 +02:00
r_iarg.default_argument = "new %s" + r_iarg.default_argument;
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
break;
Implement Vector4, Vector4i, Projection Implement built-in classes Vector4, Vector4i and Projection. * Two versions of Vector4 (float and integer). * A Projection class, which is a 4x4 matrix specialized in projection types. These types have been requested for a long time, but given they were very corner case they were not added before. Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity. **Q**: Why Projection and not Matrix4? **A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
2022-07-20 01:11:13 +02:00
case Variant::VECTOR4:
case Variant::VECTOR4I:
r_iarg.default_argument = "new %s" + r_iarg.default_argument;
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
break;
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::OBJECT:
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V_MSG(!p_val.is_zero(), false,
"Parameter of type '" + String(r_iarg.type.cname) + "' can only have null/zero as the default value.");
r_iarg.default_argument = "null";
break;
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::DICTIONARY:
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
ERR_FAIL_COND_V_MSG(!p_val.operator Dictionary().is_empty(), false,
"Default value of type 'Dictionary' must be an empty dictionary.");
// The [cs_in] expression already interprets null values as empty dictionaries.
r_iarg.default_argument = "null";
r_iarg.def_param_mode = ArgumentInterface::CONSTANT;
Added mono module
2017-10-02 23:24:00 +02:00
break;
Variant: Rename Type::_RID to Type::RID The underscore prefix was used to avoid the conflict between the `RID` class name and the matching enum value in `Variant::Type`. This can be fixed differently by prefixing uses of the `RID` class in `Variant` with the scope resolution operator, as done already for `AABB`.
2020-11-09 14:53:05 +01:00
case Variant::RID:
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
ERR_FAIL_COND_V_MSG(r_iarg.type.cname != name_cache.type_RID, false,
"Parameter of type '" + String(r_iarg.type.cname) + "' cannot have a default value of type '" + String(name_cache.type_RID) + "'.");
ERR_FAIL_COND_V_MSG(!p_val.is_zero(), false,
"Parameter of type '" + String(r_iarg.type.cname) + "' can only have null/zero as the default value.");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
r_iarg.default_argument = "default";
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
break;
Added mono module
2017-10-02 23:24:00 +02:00
case Variant::ARRAY:
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
ERR_FAIL_COND_V_MSG(!p_val.operator Array().is_empty(), false,
"Default value of type 'Array' must be an empty array.");
// The [cs_in] expression already interprets null values as empty arrays.
r_iarg.default_argument = "null";
r_iarg.def_param_mode = ArgumentInterface::CONSTANT;
Use Array.Empty instead of allocating a every time Use `System.Array.Empty<T>` to get an empty array instead of allocating a new one every time. Since arrays are immutable there is no need to allocate them every time.
2021-07-25 13:46:31 +02:00
break;
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
case Variant::PACKED_BYTE_ARRAY:
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
case Variant::PACKED_INT32_ARRAY:
case Variant::PACKED_INT64_ARRAY:
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
case Variant::PACKED_FLOAT32_ARRAY:
Variant: Added 64-bit packed arrays, renamed Variant::REAL to FLOAT. - Renames PackedIntArray to PackedInt32Array. - Renames PackedFloatArray to PackedFloat32Array. - Adds PackedInt64Array and PackedFloat64Array. - Renames Variant::REAL to Variant::FLOAT for consistency. Packed arrays are for storing large amount of data and creating stuff like meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of memory. That said, many users requested the ability to have 64 bits packed arrays for their games, so this is just an optional added type. For Variant, the float datatype is always 64 bits, and exposed as `float`. We still have `real_t` which is the datatype that can change from 32 to 64 bits depending on a compile flag (not entirely working right now, but that's the idea). It affects math related datatypes and code only. Neither Variant nor PackedArray make use of real_t, which is only intended for math precision, so the term is removed from there to keep only float.
2020-02-24 19:20:53 +01:00
case Variant::PACKED_FLOAT64_ARRAY:
PoolVector is gone, replaced by Vector Typed `PoolTypeArray` types are now renamed `PackedTypeArray` and are sugar for `Vector<Type>`.
2020-02-17 22:06:54 +01:00
case Variant::PACKED_STRING_ARRAY:
case Variant::PACKED_VECTOR2_ARRAY:
case Variant::PACKED_VECTOR3_ARRAY:
case Variant::PACKED_COLOR_ARRAY:
Use Array.Empty instead of allocating a every time Use `System.Array.Empty<T>` to get an empty array instead of allocating a new one every time. Since arrays are immutable there is no need to allocate them every time.
2021-07-25 13:46:31 +02:00
r_iarg.default_argument = "Array.Empty<%s>()";
Added mono module
2017-10-02 23:24:00 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_REF;
break;
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
case Variant::TRANSFORM2D: {
Transform2D transform = p_val.operator Transform2D();
if (transform == Transform2D()) {
r_iarg.default_argument = "Transform2D.Identity";
} else {
Rename Transform2D "elements" to "columns"
2022-04-24 23:59:24 +02:00
r_iarg.default_argument = "new Transform2D(new Vector2" + transform.columns[0].operator String() + ", new Vector2" + transform.columns[1].operator String() + ", new Vector2" + transform.columns[2].operator String() + ")";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
} break;
Rename Variant TRANSFORM to TRANSFORM3D Also _transform to _transform3d
2021-04-28 09:36:08 +02:00
case Variant::TRANSFORM3D: {
Rename Transform to Transform3D in core
2020-10-17 07:08:21 +02:00
Transform3D transform = p_val.operator Transform3D();
if (transform == Transform3D()) {
Rename files and the exposed name for Transform3D
2021-02-27 05:26:56 +01:00
r_iarg.default_argument = "Transform3D.Identity";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
} else {
Basis basis = transform.basis;
Rename files and the exposed name for Transform3D
2021-02-27 05:26:56 +01:00
r_iarg.default_argument = "new Transform3D(new Vector3" + basis.get_column(0).operator String() + ", new Vector3" + basis.get_column(1).operator String() + ", new Vector3" + basis.get_column(2).operator String() + ", new Vector3" + transform.origin.operator String() + ")";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
}
Implement Vector4, Vector4i, Projection Implement built-in classes Vector4, Vector4i and Projection. * Two versions of Vector4 (float and integer). * A Projection class, which is a 4x4 matrix specialized in projection types. These types have been requested for a long time, but given they were very corner case they were not added before. Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity. **Q**: Why Projection and not Matrix4? **A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
2022-07-20 01:11:13 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
case Variant::PROJECTION: {
Projection transform = p_val.operator Projection();
if (transform == Projection()) {
r_iarg.default_argument = "Projection.Identity";
} else {
r_iarg.default_argument = "new Projection(new Vector4" + transform.matrix[0].operator String() + ", new Vector4" + transform.matrix[1].operator String() + ", new Vector4" + transform.matrix[2].operator String() + ", new Vector4" + transform.matrix[3].operator String() + ")";
}
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
case Variant::BASIS: {
Basis basis = p_val.operator Basis();
if (basis == Basis()) {
r_iarg.default_argument = "Basis.Identity";
} else {
r_iarg.default_argument = "new Basis(new Vector3" + basis.get_column(0).operator String() + ", new Vector3" + basis.get_column(1).operator String() + ", new Vector3" + basis.get_column(2).operator String() + ")";
}
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
Rename Quat to Quaternion
2021-01-20 08:02:02 +01:00
case Variant::QUATERNION: {
Quaternion quaternion = p_val.operator Quaternion();
if (quaternion == Quaternion()) {
r_iarg.default_argument = "Quaternion.Identity";
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
} else {
Rename Quat to Quaternion
2021-01-20 08:02:02 +01:00
r_iarg.default_argument = "new Quaternion" + quaternion.operator String();
Fix C# bindings generator for default value types
2020-07-24 09:48:21 +02:00
}
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_VAL;
} break;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
case Variant::CALLABLE:
C#: Fix bindings generator for Callable argument default value Previously there weren't any Callable arguments with a default value, but d4dd859991205e6cecfa9a0553b89db47c983d0b introduced one.
2021-08-20 11:18:04 +02:00
ERR_FAIL_COND_V_MSG(r_iarg.type.cname != name_cache.type_Callable, false,
"Parameter of type '" + String(r_iarg.type.cname) + "' cannot have a default value of type '" + String(name_cache.type_Callable) + "'.");
ERR_FAIL_COND_V_MSG(!p_val.is_zero(), false,
"Parameter of type '" + String(r_iarg.type.cname) + "' can only have null/zero as the default value.");
r_iarg.default_argument = "default";
break;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
case Variant::SIGNAL:
C#: Fix bindings generator for Callable argument default value Previously there weren't any Callable arguments with a default value, but d4dd859991205e6cecfa9a0553b89db47c983d0b introduced one.
2021-08-20 11:18:04 +02:00
ERR_FAIL_COND_V_MSG(r_iarg.type.cname != name_cache.type_Signal, false,
"Parameter of type '" + String(r_iarg.type.cname) + "' cannot have a default value of type '" + String(name_cache.type_Signal) + "'.");
ERR_FAIL_COND_V_MSG(!p_val.is_zero(), false,
"Parameter of type '" + String(r_iarg.type.cname) + "' can only have null/zero as the default value.");
r_iarg.default_argument = "default";
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
break;
default:
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
ERR_FAIL_V_MSG(false, "Unexpected Variant type: " + itos(p_val.get_type()));
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
break;
Added mono module
2017-10-02 23:24:00 +02:00
}
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
if (r_iarg.def_param_mode == ArgumentInterface::CONSTANT && r_iarg.type.cname == name_cache.type_Variant && r_iarg.default_argument != "null") {
Added mono module
2017-10-02 23:24:00 +02:00
r_iarg.def_param_mode = ArgumentInterface::NULLABLE_REF;
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
return true;
Added mono module
2017-10-02 23:24:00 +02:00
}
void BindingsGenerator::_populate_builtin_type_interfaces() {
builtin_types.clear();
TypeInterface itype;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define INSERT_STRUCT_TYPE(m_type) \
{ \
itype = TypeInterface::create_value_type(String(#m_type)); \
itype.c_type_in = #m_type "*"; \
itype.c_type_out = itype.cs_type; \
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "&%0"; \
itype.cs_in_expr_is_unsafe = true; \
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
builtin_types.insert(itype.cname, itype); \
Added mono module
2017-10-02 23:24:00 +02:00
}
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
INSERT_STRUCT_TYPE(Vector2)
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
INSERT_STRUCT_TYPE(Vector2i)
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
INSERT_STRUCT_TYPE(Rect2)
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
INSERT_STRUCT_TYPE(Rect2i)
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
INSERT_STRUCT_TYPE(Transform2D)
INSERT_STRUCT_TYPE(Vector3)
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
INSERT_STRUCT_TYPE(Vector3i)
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
INSERT_STRUCT_TYPE(Basis)
Rename Quat to Quaternion
2021-01-20 08:02:02 +01:00
INSERT_STRUCT_TYPE(Quaternion)
Rename Transform to Transform3D in core
2020-10-17 07:08:21 +02:00
INSERT_STRUCT_TYPE(Transform3D)
Make C# internal calls return structs as ref parameters The Mono IL interpreter's WebAssembly to native trampolines don't support passing structs by value, so we need to do it this way. Also now we pass and return long, ulong, float and double as ref parameters as well. This is due to missing trampolines for float and long types. This is likely a temporary workaround that will be reverted in the future. The correct solution would be to patch 'mono/mini/m2n-gen.cs' when building the Mono runtime for WASM in order to generate the trampolines we need.
2019-11-14 21:48:49 +01:00
INSERT_STRUCT_TYPE(AABB)
INSERT_STRUCT_TYPE(Color)
INSERT_STRUCT_TYPE(Plane)
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_STRUCT_TYPE(Vector4)
INSERT_STRUCT_TYPE(Vector4i)
INSERT_STRUCT_TYPE(Projection)
Added mono module
2017-10-02 23:24:00 +02:00
#undef INSERT_STRUCT_TYPE
Mono: Fix NodePath and RID bindings
2018-01-25 23:44:37 +01:00
// bool
itype = TypeInterface::create_value_type(String("bool"));
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "%0.ToGodotBool()";
C#: Begin move to .NET Core We're targeting .NET 5 for now to make development easier while .NET 6 is not yet released. TEMPORARY REGRESSIONS --------------------- Assembly unloading is not implemented yet. As such, many Godot resources are leaked at exit. This will be re-implemented later together with assembly hot-reloading.
2021-09-12 20:23:05 +02:00
itype.cs_out = "%5return %0(%1).ToBool();";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "godot_bool";
itype.c_type_in = itype.c_type;
itype.c_type_out = itype.c_type;
itype.c_arg_in = "&%s";
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromBool(%1);\n";
Mono: Fix NodePath and RID bindings
2018-01-25 23:44:37 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
// Integer types
C#: Optimize struct marshalling - We no longer box struct to return them from internal calls. - Use reinterpret_cast if the managed struct layout is the same as the native struct.
2018-10-17 21:37:57 +02:00
{
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
// C interface for 'uint32_t' is the same as that of enums. Remember to apply
// any of the changes done here to 'TypeInterface::postsetup_enum_type' as well.
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define INSERT_INT_TYPE(m_name) \
{ \
itype = TypeInterface::create_value_type(String(m_name)); \
if (itype.name != "long" && itype.name != "ulong") { \
itype.c_in = "%5%0 %1_in = %1;\n"; \
itype.c_out = "%5return (%0)%1;\n"; \
itype.c_type = "long"; \
itype.c_arg_in = "&%s_in"; \
} else { \
itype.c_arg_in = "&%s"; \
} \
itype.c_type_in = itype.name; \
itype.c_type_out = itype.name; \
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromInt(%1);\n"; \
builtin_types.insert(itype.cname, itype); \
C#: Optimize struct marshalling - We no longer box struct to return them from internal calls. - Use reinterpret_cast if the managed struct layout is the same as the native struct.
2018-10-17 21:37:57 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
// The expected type for all integers in ptrcall is 'int64_t', so that's what we use for 'c_type'
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_INT_TYPE("sbyte");
INSERT_INT_TYPE("short");
INSERT_INT_TYPE("int");
INSERT_INT_TYPE("long");
INSERT_INT_TYPE("byte");
INSERT_INT_TYPE("ushort");
INSERT_INT_TYPE("uint");
INSERT_INT_TYPE("ulong");
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#undef INSERT_INT_TYPE
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
// Floating point types
C#: Optimize struct marshalling - We no longer box struct to return them from internal calls. - Use reinterpret_cast if the managed struct layout is the same as the native struct.
2018-10-17 21:37:57 +02:00
{
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
// float
itype = TypeInterface();
itype.name = "float";
itype.cname = itype.name;
itype.proxy_name = "float";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.cs_type = itype.proxy_name;
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
{
// The expected type for 'float' in ptrcall is 'double'
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_in = "%5%0 %1_in = %1;\n";
itype.c_out = "%5return (%0)%1;\n";
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
itype.c_type = "double";
itype.c_arg_in = "&%s_in";
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_in = itype.proxy_name;
itype.c_type_out = itype.proxy_name;
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromFloat(%1);\n";
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
builtin_types.insert(itype.cname, itype);
// double
itype = TypeInterface();
itype.name = "double";
itype.cname = itype.name;
itype.proxy_name = "double";
itype.cs_type = itype.proxy_name;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "double";
itype.c_arg_in = "&%s";
itype.c_type_in = itype.proxy_name;
itype.c_type_out = itype.proxy_name;
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromFloat(%1);\n";
C#: Generate the correct integer and floating point types
2019-04-25 20:24:48 +02:00
builtin_types.insert(itype.cname, itype);
C#: Optimize struct marshalling - We no longer box struct to return them from internal calls. - Use reinterpret_cast if the managed struct layout is the same as the native struct.
2018-10-17 21:37:57 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
// String
itype = TypeInterface();
itype.name = "String";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = "string";
itype.cs_type = itype.proxy_name;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_in = "%5using %0 %1_in = " C_METHOD_MONOSTR_TO_GODOT "(%1);\n";
C#: Restructure code prior move to .NET Core The main focus here was to remove the majority of code that relied on Mono's embedding APIs, specially the reflection APIs. The embedding APIs we still use are the bare minimum we need for things to work. A lot of code was moved to C#. We no longer deal with any managed objects (`MonoObject*`, and such) in native code, and all marshaling is done in C#. The reason for restructuring the code and move away from embedding APIs is that once we move to .NET Core, we will be limited by the much more minimal .NET hosting. PERFORMANCE REGRESSIONS ----------------------- Some parts of the code were written with little to no concern about performance. This includes code that calls into script methods and accesses script fields, properties and events. The reason for this is that all of that will be moved to source generators, so any work prior to that would be a waste of time. DISABLED FEATURES ----------------- Some code was removed as it no longer makes sense (or won't make sense in the future). Other parts were commented out with `#if 0`s and TODO warnings because it doesn't make much sense to work on them yet as those parts will change heavily when we switch to .NET Core but also when we start introducing source generators. As such, the following features were disabled temporarily: - Assembly-reloading (will be done with ALCs in .NET Core). - Properties/fields exports and script method listing (will be handled by source generators in the future). - Exception logging in the editor and stack info for errors. - Exporting games. - Building of C# projects. We no longer copy the Godot API assemblies to the project directory, so MSBuild won't be able to find them. The idea is to turn them into NuGet packages in the future, which could also be obtained from local NuGet sources during development.
2021-09-12 20:21:15 +02:00
itype.c_out = "%5return " C_METHOD_MONOSTR_FROM_GODOT "(%1);\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_arg_in = "&%s_in";
itype.c_type = "godot_string";
itype.c_type_in = itype.cs_type;
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = true;
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromStringTakingOwnershipOfDisposableValue(" C_METHOD_MONOSTR_TO_GODOT "(%1));\n";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
// StringName
itype = TypeInterface();
itype.name = "StringName";
itype.cname = itype.name;
itype.proxy_name = "StringName";
itype.cs_type = itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "(%1)(%0?.NativeValue ?? default)";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Cannot pass null StringName to ptrcall
itype.c_out = "%5return %0.CreateTakingOwnershipOfDisposableValue(%1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_arg_in = "&%s";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "godot_string_name";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_type_in = itype.c_type;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_out = itype.cs_type;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_in_vararg = "%5using godot_variant %1_in = VariantUtils.CreateFromStringName(%1);\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_is_disposable_struct = false; // [c_out] takes ownership
itype.c_ret_needs_default_initialization = true;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// NodePath
itype = TypeInterface();
itype.name = "NodePath";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = "NodePath";
itype.cs_type = itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "(%1)(%0?.NativeValue ?? default)";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Cannot pass null NodePath to ptrcall
itype.c_out = "%5return %0.CreateTakingOwnershipOfDisposableValue(%1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_arg_in = "&%s";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "godot_node_path";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_type_in = itype.c_type;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = false; // [c_out] takes ownership
itype.c_ret_needs_default_initialization = true;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// RID
itype = TypeInterface();
itype.name = "RID";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = "RID";
itype.cs_type = itype.proxy_name;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_arg_in = "&%s";
itype.c_type = itype.cs_type;
itype.c_type_in = itype.c_type;
itype.c_type_out = itype.c_type;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// Variant
itype = TypeInterface();
itype.name = "Variant";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = "object";
itype.cs_type = itype.proxy_name;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_in = "%5using %0 %1_in = " C_METHOD_MANAGED_TO_VARIANT "(%1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_out = "%5return " C_METHOD_MANAGED_FROM_VARIANT "(%1);\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_arg_in = "&%s_in";
itype.c_type = "godot_variant";
itype.c_type_in = itype.cs_type;
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = true;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
// Callable
itype = TypeInterface::create_value_type(String("Callable"));
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "ref %0";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_in = "%5using %0 %1_in = " C_METHOD_MANAGED_TO_CALLABLE "(ref %1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_out = "%5return " C_METHOD_MANAGED_FROM_CALLABLE "(in %1);\n";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_arg_in = "&%s_in";
itype.c_type = "godot_callable";
itype.c_type_in = "ref " + itype.cs_type;
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = true;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
builtin_types.insert(itype.cname, itype);
// Signal
itype = TypeInterface();
itype.name = "Signal";
itype.cname = itype.name;
itype.proxy_name = "SignalInfo";
itype.cs_type = itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "ref %0";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_in = "%5using %0 %1_in = " C_METHOD_MANAGED_TO_SIGNAL "(ref %1);\n";
itype.c_out = "%5return " C_METHOD_MANAGED_FROM_SIGNAL "(&%1);\n";
itype.c_arg_in = "&%s_in";
itype.c_type = "godot_signal";
itype.c_type_in = "ref " + itype.cs_type;
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = true;
Fix C# bindings after recent breaking changes Implementation for new Variant types Callable, Signal, StringName. Added support for PackedInt64Array and PackedFloat64Array. Add generation of signal members as events, as well as support for user created signals as events. NOTE: As of now, raising such events will not emit the signal. As such, one must use `EmitSignal` instead of raising the event directly. Removed old ThreadLocal fallback class. It's safe to use thread_local now since it's supported on all minimum versions of compilers we support.
2020-03-14 19:20:17 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// VarArg (fictitious type to represent variable arguments)
itype = TypeInterface();
itype.name = "VarArg";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = "object[]";
itype.cs_type = "params object[]";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "%0 ?? Array.Empty<object>()";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// c_type, c_in and c_arg_in are hard-coded in the generator.
// c_out and c_type_out are not applicable to VarArg.
itype.c_arg_in = "&%s_in";
itype.c_type_in = "object[]";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define INSERT_ARRAY_FULL(m_name, m_type, m_managed_type, m_proxy_t) \
{ \
itype = TypeInterface(); \
itype.name = #m_name; \
itype.cname = itype.name; \
itype.proxy_name = #m_proxy_t "[]"; \
itype.cs_type = itype.proxy_name; \
itype.c_in = "%5using %0 %1_in = " C_METHOD_MONOARRAY_TO(m_type) "(%1);\n"; \
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_out = "%5return " C_METHOD_MONOARRAY_FROM(m_type) "(%1);\n"; \
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_arg_in = "&%s_in"; \
itype.c_type = #m_managed_type; \
itype.c_type_in = itype.proxy_name; \
itype.c_type_out = itype.proxy_name; \
itype.c_type_is_disposable_struct = true; \
builtin_types.insert(itype.name, itype); \
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
#define INSERT_ARRAY(m_type, m_managed_type, m_proxy_t) INSERT_ARRAY_FULL(m_type, m_type, m_managed_type, m_proxy_t)
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_ARRAY(PackedInt32Array, godot_packed_int32_array, int);
INSERT_ARRAY(PackedInt64Array, godot_packed_int64_array, long);
INSERT_ARRAY_FULL(PackedByteArray, PackedByteArray, godot_packed_byte_array, byte);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_ARRAY(PackedFloat32Array, godot_packed_float32_array, float);
INSERT_ARRAY(PackedFloat64Array, godot_packed_float64_array, double);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_ARRAY(PackedStringArray, godot_packed_string_array, string);
Added mono module
2017-10-02 23:24:00 +02:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
INSERT_ARRAY(PackedColorArray, godot_packed_color_array, Color);
INSERT_ARRAY(PackedVector2Array, godot_packed_vector2_array, Vector2);
INSERT_ARRAY(PackedVector3Array, godot_packed_vector3_array, Vector3);
Added mono module
2017-10-02 23:24:00 +02:00
#undef INSERT_ARRAY
Add Array and Dictionary wrapper classes to C#
2018-07-18 23:07:57 +02:00
// Array
itype = TypeInterface();
itype.name = "Array";
itype.cname = itype.name;
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
itype.proxy_name = itype.name;
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
itype.type_parameter_count = 1;
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
itype.cs_type = BINDINGS_NAMESPACE_COLLECTIONS "." + itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "(%1)(%0 ?? new()).NativeValue";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_out = "%5return %0.CreateTakingOwnershipOfDisposableValue(%1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_arg_in = "&%s";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "godot_array";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_type_in = itype.c_type;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = false; // [c_out] takes ownership
itype.c_ret_needs_default_initialization = true;
builtin_types.insert(itype.cname, itype);
// Array_@generic
// Re-use Array's itype
itype.name = "Array_@generic";
itype.cname = itype.name;
itype.cs_out = "%5return new %2(%0(%1));";
Add Array and Dictionary wrapper classes to C#
2018-07-18 23:07:57 +02:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// Dictionary
itype = TypeInterface();
itype.name = "Dictionary";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
itype.proxy_name = itype.name;
Generate typed array parameters in C# bindings Adds support for generating C# bindings that use the generic `Array<T>` type instead of the non-generic `Array` type when the registered ClassDB method specifies the array element type.
2022-02-09 00:56:10 +01:00
itype.type_parameter_count = 2;
C# generated classes ignore warning CS1591 and cleanup
2018-08-27 20:39:51 +02:00
itype.cs_type = BINDINGS_NAMESPACE_COLLECTIONS "." + itype.proxy_name;
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.cs_in_expr = "(%1)(%0 ?? new()).NativeValue";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_out = "%5return %0.CreateTakingOwnershipOfDisposableValue(%1);\n";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_arg_in = "&%s";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type = "godot_dictionary";
C#: Code cleanup and greatly reduce use of C# pointers
2021-12-28 23:25:16 +01:00
itype.c_type_in = itype.c_type;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.c_type_out = itype.cs_type;
itype.c_type_is_disposable_struct = false; // [c_out] takes ownership
itype.c_ret_needs_default_initialization = true;
builtin_types.insert(itype.cname, itype);
// Dictionary_@generic
// Re-use Dictionary's itype
itype.name = "Dictionary_@generic";
itype.cname = itype.name;
itype.cs_out = "%5return new %2(%0(%1));";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
// void (fictitious type to represent the return type of methods that do not return anything)
itype = TypeInterface();
itype.name = "void";
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
itype.cname = itype.name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.proxy_name = itype.name;
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
itype.cs_type = itype.proxy_name;
itype.c_type = itype.proxy_name;
Added mono module
2017-10-02 23:24:00 +02:00
itype.c_type_in = itype.c_type;
itype.c_type_out = itype.c_type;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
builtin_types.insert(itype.cname, itype);
Added mono module
2017-10-02 23:24:00 +02:00
}
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
void BindingsGenerator::_populate_global_constants() {
Reorganized core/ directory, it was too fatty already -Removed FuncRef, since Callable makes it obsolete -Removed int_types.h as its obsolete in c++11+ -Changed color names code
2020-11-07 23:33:38 +01:00
int global_constants_count = CoreConstants::get_global_constant_count();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (global_constants_count > 0) {
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
HashMap<String, DocData::ClassDoc>::Iterator match = EditorHelp::get_doc_data()->class_list.find("@GlobalScope");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace 'ERR_EXPLAIN' with 'ERR_FAIL_*_MSG' in 'modules/mono' And 'CRASH_*_MSG' as well. Also make error messages puntuation and quotation more consistent.
2019-08-09 03:39:45 +02:00
CRASH_COND_MSG(!match, "Could not find '@GlobalScope' in DocData.");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace most uses of Map by HashMap * Map is unnecessary and inefficient in almost every case. * Replaced by the new HashMap. * Renamed Map to RBMap and Set to RBSet for cases that still make sense (order matters) but use is discouraged. There were very few cases where replacing by HashMap was undesired because keeping the key order was intended. I tried to keep those (as RBMap) as much as possible, but might have missed some. Review appreciated!
2022-05-13 15:04:37 +02:00
const DocData::ClassDoc &global_scope_doc = match->value;
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
for (int i = 0; i < global_constants_count; i++) {
Reorganized core/ directory, it was too fatty already -Removed FuncRef, since Callable makes it obsolete -Removed int_types.h as its obsolete in c++11+ -Changed color names code
2020-11-07 23:33:38 +01:00
String constant_name = CoreConstants::get_global_constant_name(i);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Replace NULL with nullptr
2020-04-02 01:20:12 +02:00
const DocData::ConstantDoc *const_doc = nullptr;
Fix GCC compiler warning in mono module - thread_local.h: 'delegating constructors only available with -std=c++11 or -std=gnu++11' - mono_reg_utils.cpp: 'extra tokens at end of #endif directive' - mono_bottom_panel.cpp: '<fieldB> will be initialized after <fieldA> when initialized here' - bindings_generator.cpp: 'name lookup of 'i' changed (...) matches this 'i' under ISO standard rules (...) matches this 'i' under old rules (...)'
2018-10-03 00:56:28 +02:00
for (int j = 0; j < global_scope_doc.constants.size(); j++) {
const DocData::ConstantDoc &curr_const_doc = global_scope_doc.constants[j];
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (curr_const_doc.name == constant_name) {
const_doc = &curr_const_doc;
break;
}
}
Make enum/constant binds 64-bit.
2022-05-09 11:47:10 +02:00
int64_t constant_value = CoreConstants::get_global_constant_value(i);
Reorganized core/ directory, it was too fatty already -Removed FuncRef, since Callable makes it obsolete -Removed int_types.h as its obsolete in c++11+ -Changed color names code
2020-11-07 23:33:38 +01:00
StringName enum_name = CoreConstants::get_global_constant_enum(i);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
ConstantInterface iconstant(constant_name, snake_to_pascal_case(constant_name, true), constant_value);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
iconstant.const_doc = const_doc;
if (enum_name != StringName()) {
EnumInterface ienum(enum_name);
Add C# support for bitfield enums (flags)
2022-06-24 20:25:30 +02:00
// TODO: ienum.is_flags is always false for core constants since they don't seem to support bitfield enums
Add -Wshadow=local to warnings and fix reported issues. Fixes #25316.
2019-02-12 21:10:08 +01:00
List<EnumInterface>::Element *enum_match = global_enums.find(ienum);
if (enum_match) {
enum_match->get().constants.push_back(iconstant);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
} else {
ienum.constants.push_back(iconstant);
global_enums.push_back(ienum);
}
} else {
global_constants.push_back(iconstant);
}
}
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (EnumInterface &ienum : global_enums) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
TypeInterface enum_itype;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
enum_itype.is_enum = true;
enum_itype.name = ienum.cname.operator String();
enum_itype.cname = ienum.cname;
enum_itype.proxy_name = enum_itype.name;
TypeInterface::postsetup_enum_type(enum_itype);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
enum_types.insert(enum_itype.cname, enum_itype);
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
int prefix_length = _determine_enum_prefix(ienum);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
// HARDCODED: The Error enum have the prefix 'ERR_' for everything except 'OK' and 'FAILED'.
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
if (ienum.cname == name_cache.enum_Error) {
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
if (prefix_length > 0) { // Just in case it ever changes
Remove duplicate ERR_PRINT macro.
2019-11-06 17:03:04 +01:00
ERR_PRINT("Prefix for enum '" _STR(Error) "' is not empty.");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
prefix_length = 1; // 'ERR_'
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
Fix prefix erasing for the generated C# enum constants
2018-10-18 19:41:10 +02:00
_apply_prefix_to_enum_constants(ienum, prefix_length);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
}
}
// HARDCODED
List<StringName> hardcoded_enums;
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
hardcoded_enums.push_back("Vector2.Axis");
hardcoded_enums.push_back("Vector2i.Axis");
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
hardcoded_enums.push_back("Vector3.Axis");
[Mono] Marshaling for Vector2i, Vector3i, and Rect2i
2020-03-03 10:42:20 +01:00
hardcoded_enums.push_back("Vector3i.Axis");
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
for (const StringName &enum_cname : hardcoded_enums) {
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
// These enums are not generated and must be written manually (e.g.: Vector3.Axis)
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
// Here, we assume core types do not begin with underscore
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
TypeInterface enum_itype;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
enum_itype.is_enum = true;
Fix bindings generator range iterator errors
2021-07-25 18:45:00 +02:00
enum_itype.name = enum_cname.operator String();
enum_itype.cname = enum_cname;
Mono: BindingsGenerator enum fixes - Make enums have an unique signature name of int. This means that when generating internal methods, there is no difference between different enums types nor between enums and int. This way enums can re-use internal methods. - Make type resolver fallback to int if a type is not found and it's an enum.
2018-04-28 22:25:25 +02:00
enum_itype.proxy_name = enum_itype.name;
TypeInterface::postsetup_enum_type(enum_itype);
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
enum_types.insert(enum_itype.cname, enum_itype);
}
}
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
void BindingsGenerator::_initialize_blacklisted_methods() {
blacklisted_methods["Object"].push_back("to_string"); // there is already ToString
blacklisted_methods["Object"].push_back("_to_string"); // override ToString instead
blacklisted_methods["Object"].push_back("_init"); // never called in C# (TODO: implement it)
}
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
void BindingsGenerator::_log(const char *p_format, ...) {
if (log_print_enabled) {
va_list list;
va_start(list, p_format);
OS::get_singleton()->print("%s", str_format(p_format, list).utf8().get_data());
va_end(list);
}
}
void BindingsGenerator::_initialize() {
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
initialized = false;
Added mono module
2017-10-02 23:24:00 +02:00
EditorHelp::generate_doc();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
enum_types.clear();
C#: Implement ScriptInstance::to_string Create a blacklist of methods that must not be generated. Includes: "to_string", "_to_string" and "_init".
2019-05-24 00:40:16 +02:00
_initialize_blacklisted_methods();
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
bool obj_type_ok = _populate_object_type_interfaces();
ERR_FAIL_COND_MSG(!obj_type_ok, "Failed to generate object type interfaces");
Added mono module
2017-10-02 23:24:00 +02:00
_populate_builtin_type_interfaces();
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
_populate_global_constants();
Cleanup of c# api files and bindings generator - We no longer generate RID and NodePath C# classes. Both will be maintained manually. - We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base). - We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class. This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code). - Added missing 'RID(Object from)' constructor to the RID C# class. - Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED. - Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
2018-09-04 05:40:41 +02:00
// Generate internal calls (after populating type interfaces and global constants)
Mono: Make the bindings generator output enums - Switch to PascalCase for constants names
2017-12-24 03:17:48 +01:00
Add a new HashMap implementation Adds a new, cleaned up, HashMap implementation. * Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing). * Keeps elements in a double linked list for simpler, ordered, iteration. * Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much for performance vs keeping the key, but helps replace old code). * Uses a more modern C++ iterator API, deprecates the old one. * Supports custom allocator (in case there is a wish to use a paged one). This class aims to unify all the associative template usage and replace it by this one: * Map<> (whereas key order does not matter, which is 99% of cases) * HashMap<> * OrderedHashMap<> * OAHashMap<>
2022-05-08 10:09:19 +02:00
for (const KeyValue<StringName, TypeInterface> &E : obj_types) {
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
const TypeInterface &itype = E.value;
Error err = _populate_method_icalls_table(itype);
ERR_FAIL_COND_MSG(err != OK, "Failed to generate icalls table for type: " + itype.name);
Added tests for ClassDB
2020-05-16 04:03:05 +02:00
}
Improve C# bindings generator errors for default param values
2019-09-24 15:09:54 +02:00
initialized = true;
Added mono module
2017-10-02 23:24:00 +02:00
}
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
static String generate_all_glue_option = "--generate-mono-glue";
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
static void handle_cmdline_options(String glue_dir_path) {
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
BindingsGenerator bindings_generator;
bindings_generator.set_log_print_enabled(true);
if (!bindings_generator.is_initialized()) {
ERR_PRINT("Failed to initialize the bindings generator");
return;
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
CRASH_COND(glue_dir_path.is_empty());
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (bindings_generator.generate_cs_api(glue_dir_path.plus_file(API_SOLUTION_NAME)) != OK) {
ERR_PRINT(generate_all_glue_option + ": Failed to generate the C# API.");
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
}
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
static void cleanup_and_exit_godot() {
// Exit once done
Main::cleanup(true);
::exit(0);
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
}
Added mono module
2017-10-02 23:24:00 +02:00
void BindingsGenerator::handle_cmdline_args(const List<String> &p_cmdline_args) {
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
String glue_dir_path;
C#: Fix StringName leak warnings after generating bindings `Main::cleanup()` prints warnings if it finds `StringName`s still alive. We need the `BindingsGenerator` to be destructed before calling cleanup.
2021-03-13 01:16:27 +01:00
Added mono module
2017-10-02 23:24:00 +02:00
const List<String>::Element *elem = p_cmdline_args.front();
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
while (elem) {
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
if (elem->get() == generate_all_glue_option) {
Added mono module
2017-10-02 23:24:00 +02:00
const List<String>::Element *path_elem = elem->next();
if (path_elem) {
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
glue_dir_path = path_elem->get();
Added mono module
2017-10-02 23:24:00 +02:00
elem = elem->next();
} else {
Remove duplicate ERR_PRINT macro.
2019-11-06 17:03:04 +01:00
ERR_PRINT(generate_all_glue_option + ": No output directory specified (expected path to '{GODOT_ROOT}/modules/mono/glue').");
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
// Exit once done with invalid command line arguments
cleanup_and_exit_godot();
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
break;
Added mono module
2017-10-02 23:24:00 +02:00
}
elem = elem->next();
}
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
if (glue_dir_path.length()) {
handle_cmdline_options(glue_dir_path);
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
// Exit once done
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 15:21:06 +02:00
cleanup_and_exit_godot();
C# bindings generator cleanup - Normal log messages are no longer warnings. - BindingsGenerator is no longer a singleton. - Added a log function.
2019-04-25 15:45:12 +02:00
}
Added mono module
2017-10-02 23:24:00 +02:00
}
#endif
Reference in a new issue Copy permalink