As our script class parser is error prone, we should not impede the build from continuing because of a parsing error.
This should be reverted in the future once we switch to Roslyn.
Commit 4d727f1ee6 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.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
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.
MSBuild on Windows uses the system .NET Framework BCL instead of Mono's. Because
of this, it may not be able to find the Mono.Posix assembly, so it's better
not to depend on it. We needed Mono.Posix to call Syscall.access, so we can
replace this with an internal call that does the same in C++.
`Variant::operator String()` returns "Null" if the type is `Variant:NIL`.
We must consider that and return a null `MonoString*` instead when marshalling.
This was also causing a "Null" error to be displayed when exporting a game
because null string members would be set to "Null" during hot-reload.
d09193b08a introduced a regression in
StringExtensions.FindLast. StringExtensions.GetFile was also affected as it
relies on FindLast. This in turn broke the project exporter as it uses GetFile.
The cause of the regression is that now FindLast is calling LastIndexOf
with 'startIndex: 0'. This should be 'startIndex: str.Length - 1' instead.
Also fixed another regression in the project exporter:
de7c2ad21b moved 'GodotTools/GodotSharpExport.cs'
to 'GodotTools/Export/ExportPlugin.cs' and in doing so accidently reverted
the changes from commit e439581198.
It would incorrectly error thinking the nested namespace is being declared inside a struct/class. This was because of an incorrect nesting level being used for classes and structs.
- Added correct config file for android dllmaps.
- Fix __Internal DllImports with a dlopen fallback.
- Add missing P/Invoke functions and internal calls expected by the monodroid BCL and our custom version of the 'Android.Runtime.AndroidEnvironment' class (this last one can be found in the godot-mono-builds repo).
- Make sure to set 'btls' instead of 'legacy' as the default TLS provider on Android.
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.
This was a wrong check as an exit code of 0 means success,
not failure. It used to be fine as blocking mode always returned
-2, but this was changed in #32033 to return the exit code.
Fixes#32424.
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.
Assembly paths were written to PCK files with backslash as path separator and PackedData only supports forward slash.
This would make exported games unable to find the assemblies.
This will be used for communicating between the Godot editor and external IDEs/editors, for things like opening files, triggering hot-reload and running the game with a debugger attached.
Mono's MSBuild and System/VisualStudio's MSBuild expect a different format for surrounding property values with quotes on the command line.
xbuild does not seem to support semicolons in property values from the command line: https://xamarin.github.io/bugzilla-archives/16/16465/bug.html
It's a good time to just remove xbuild support entirely.
Remove the old API assembly invalidation system. It's pretty simple since now the editor has a hard dependency on the API assemblies and SCons takes care of prebuilding them.
If we fail to load a project's API assembly because it was either missing or outdated, we just copy the prebuilt assemblies to the project and try again. We also do this when creating the solution and before building, just in case the user removed them from the disk after they were loaded.
This way the API assemblies will be always loaded successfully. If they are not, it's a bug.
Also fixed:
- EditorDef was behaving like GlobalDef in GodotTools.
- NullReferenceException because we can't serialize System.WeakReference yet. Use Godot.WeakRef in the mean time.
We need to dispose the GodotSharpExport export plugin before the editor destroys EditorSettings. Otherwise, if the GC disposes it at a later time, EditorExportPlatformAndroid will be freed after EditorSettings already was, and its device polling thread will try to access the EditorSettings singleton, resulting in null dereferencing.
ptrcall assumes methods that return a Reference type do so with Ref<T>. Returning Reference* from a method exposed to the scripting API completely breaks ptrcalls to this method (it can be quite hard to debug!).
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.
This adds constants to projects build via Godot Mono which allows project to conditionally react to different operating systems and 32/64 Bit architecture. Additionally .NET libraries could support multiple engines like Unity and Godot at the same time when compiled from Godot and reacting to definitions.
- Only load the scripts metadata file when it's really needed. This way we avoid false errors, when there is no C# project, about missing scripts metadata file.
- 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.
It seems to stay compatible with formatting done by clang-format 6.0 and 7.0,
so contributors can keep using those versions for now (they will not undo those
changes).
Adds `FALLTHROUGH` macro to specify when a fallthrough is intentional.
Can be replaced by `[[fallthrough]]` if/when we switch to C++17.
The warning is now enabled by default for GCC on `extra` warnings level
(part of GCC's `-Wextra`). It's not enabled in Clang's `-Wextra` yet,
but we could enable it manually once we switch to C++11. There's no
equivalent feature in MSVC for now.
Fixes#26135.
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).
Expands to Object.call, Object.set and Object.get for accessing members. This means it can also access members from scripts written in other languages, like GDScript.
- Move "Mono" popup menu from the top right corner to `Projects -> Tools` as a submenu.
- Add "Build solution" button to the top right corner. Makes it more visible and quicker to access.
- Fix build list in the bottom panel unselect an item when clicking on empty space. Previously it would hide the issues panel but the item would remain selected, making it impossible to display the issues panel again if there was only one item.
This property returns an instance of the singleton.
The purpose of this is to allow using methods from the base class like 'Connect'.
Since all Godot singletons inherit Object, the type of the returned instance is Godot.Object.
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.
Previously this was only done when building the script for running the game. This was a problem because the user could want to build the project manually with the "Build project" button, to then run the game from the command line or similar.
BaseIntermediateOutputPath seems to be empty by default. The workaround is to explicitly set it.
Also fixed passing char instead of char[] to String.Split. Why was this even working with Mono?
This fixes the previously wrong PR
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes#24752
Because we don't actually ship 'debug' templates to users make sure
the mono exporter picks the correct 'data' directory for export
templates.
This fixes#24752
- 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>'
- `modules\mono\csharp_script.cpp(576): warning C4099: 'CSharpScriptDepSort': type name first seen using 'class' now seen using 'struct'`
- `modules\mono\signal_awaiter_utils.cpp(144): warning C4003: not enough actual parameters for macro 'ERR_FAIL_V'`
- `modules\mono\editor\net_solution.cpp(101): warning C4129: '%': unrecognized character escape sequence`
- (several) `modules\mono\glue\cs_compressed.gen.h(222): warning C4129: 'E': unrecognized character escape sequence`
- If there is a solution and C# project at startup, make sure API assemblies are up to date.
- Fix prebuilt assemblies only being used when building the game project, and not in other instances.
- Bundle editor dependencies:
- 'GodotSharp': Root data directory for the editor
- 'Tools': Editor dependencies. Only GodotSharp.dll for now.
- 'Api': Prebuilt GodotSharp and GodotSharpEditor API assemblies.
- 'Mono': Mono files to bundle with the editor.
- 'bin': (Optional, not used for now) Mono bin directory.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- 'lib/mono/4.5': Framework assemblies.
- Added build option to copy the required files from the mono installation to 'GodotSharp/Mono'. Enable with 'copy_mono_root=yes'. Disabled by default.
- Export template dependencies:
- 'data_AppName'/'data_Godot':
- 'Mono': Mono files to bundle with the game.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- The data directory is generated when compiling and must be bundled with the export templates. In the case of OSX, the data directory must be placed inside the 'osx.zip' export template.
- In OSX, alternative location for directories (needed for app bundles) are:
- 'data_AppName/Mono/etc' --> '../Resources/GodotSharp/Mono/etc'
- 'data_AppName/Mono/lib' --> '../Frameworks/GodotSharp/Mono/lib'
- The editor can bundle prebuilt API assemblies.
- Generate them with a tools build by running: `--generate-cs-core-api <GodotSharp_OutputDir> --generate-cs-editor-api <GodotSharpEditor_OutputDir> <GodotSharp_OutputDir>/bin/Release/GodotSharp.dll` (This command will be simplified in the future and both projects will be in the same solution)
- Build the solutions and copy the output files to '#bin/GodotSharp/Api'.
- Fixed API assembly being added twice during the export process.
- 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 (...)'
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.
When a Reference managed instance is garbage collected and its finalizer is called, it could happen that the native instance is referenced once again before the finalizer can unreference and memdelete it. The workaround is to create a new managed instance when this happens (at least for now).
- 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.
This commit makes operator[] on Vector const and adds a write proxy to it. From
now on writes to Vectors need to happen through the .write proxy. So for
instance:
Vector<int> vec;
vec.push_back(10);
std::cout << vec[0] << std::endl;
vec.write[0] = 20;
Failing to use the .write proxy will cause a compilation error.
In addition COWable datatypes can now embed a CowData pointer to their data.
This means that String, CharString, and VMap no longer use or derive from
Vector.
_ALWAYS_INLINE_ and _FORCE_INLINE_ are now equivalent for debug and non-debug
builds. This is a lot faster for Vector in the editor and while running tests.
The reason why this difference used to exist is because force-inlined methods
used to give a bad debugging experience. After extensive testing with modern
compilers this is no longer the case.
I've removed the section about being unable to export games using C# - as you are now able to do this, as long as the export templates are installed. Also, I've made a few minor grammar tweaks.
On macOS, it is common to install packages like Mono through the third-party
package-manager Homebrew. This commit simply adds an additional path to
where Homebrew installs the Mono framework.
- Add option to print MSBuild's stdout and stderr instead of redirecting it. This can be enabled by setting the environment variable: Godot_DEBUG_MSBUILD=1
- Set (Csc/Vbc/Fsc)ToolExe environment variables to point to the batch files in Mono's bin directory when building with Mono's MSBuild.
- Set Mono's MSBuild as the default build tool on Windows.
- Generate projects with portable DebugType instead of full.
- 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.
It already had an implicit cast operator to string,
but this doesn't get used in say string formatting.
So now something like $"path: {GetPath()}" works.
This ensures that all users of the Mono flavour of Godot 3.0 are aware
of its current shortcomings (no export, crashes and usability issues).
The dialog is shown each time the editor is started, until the checkbox
is disabled (i.e. until users will have actually read it).
Fixes#15956.
- Fix VS Code opening on the previous line to the desired one.
- Fix running MonoDevelop without the line and column parameters.
- Fix `ScriptEditor::_goto_script_line` not working with language overriden external editors.
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.
- alloc_language_binding: Use strong GC handle as well for references. Fixes#15138
- Set the native instance field of Godot.Object to IntPtr.Zero when it's freed.
- Create weak handles without tracking resurrection (that was causing trouble). This means we have to call notification predelete before queueing a native Object for deletion, and use the MonoObject* passed by the finalizer because the weak GC handle target will return NULL at this point.
Should fix issues some of us have with `misc/dist/uwp_template/AppxManifest.xml`
always showing up as modified.
Might cause issues on Windows due to the removal of BOMs or change of line endings
in some of the Mono, UWP or gradlew.bat files, we will test and adapt if need be.
- Make sure to search the mono installation directory for the right architecture in the windows registry.
- Do not build GodotSharpTools directly to #bin dir. Instead build to the default output path and copy it. This way we avoid MSBuild adding files we don't want to #bin.
- Add hint path for MSBuild in OSX.
- Copy shared library on Unix if not statically linking.
- Use vswhere to search MSBuild and search for 14.0 tools version in the registry instead of 4.0.
- SCons will only fallback xbuild when msbuild is not found if 'xbuild_fallback=yes' is passed to the command.
- Use mono's assembly path as FrameworkPathOverride if using with system's MSBuild (not mono's fork).
- Cleanup.
