We've been using standard C library functions `memcpy`/`memset` for these since
2016 with 67f65f6639.
There was still the possibility for third-party platform ports to override the
definitions with a custom header, but this doesn't seem useful anymore.
Backport of #48239.
- Based on C++11's `atomic`
- Reworked `SafeRefCount` (based on the rewrite by @hpvb)
- Replaced free atomic functions by the new `SafeNumeric<T>`
- Replaced wrong cases of `volatile` by the new `SafeFlag`
- Platform-specific implementations no longer needed
Co-authored-by: Hein-Pieter van Braam-Stewart <hp@tmm.cx>
- Based on C++11's `mutex`
- No more need to allocate-deallocate or check for null
- No pointer anymore, just a member variable
- Platform-specific implementations no longer needed
- Simpler for `NO_THREADS`
- `BinaryMutex` added for special cases as the non-recursive version
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
(cherry picked from commit b5334d14f7)
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
(cherry picked from commit cd4e46ee65)
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.
VarArg methods have the return type Object in the API json for GDNative. This
can cause undefined behavior in some language bindings due to lack of
documentation on VarArg methods' behavior.
This changes the MethodInfo of:
- CSharpScript::_new
- GDScript::_new
- PluginScript::_new
It's the recommended way to set those, and is more portable
(automatically prepends -D for GCC/Clang and /D for MSVC).
We still use CPPFLAGS for some pre-processor flags which are not
defines.
ResourceFormatLoader and ResourceFormatSaver are meant to be overridden
to add support for different formats in ResourceLoader and ResourceSaver.
Those should be exposed as they can be overridden in plugins.
On the other hand, all predefined subclasses of those two base classes
are only meant to register support for new file and resource types, but
should not and cannot be used directly from script, so they should not
be exposed.
Also unexposed ResourceImporterOGGVorbis (and thus its base class
ResourceImporter) which are editor-only.
binding_functions.size() and an instance's binding_data.size() can get out of sync. They sync up when an instance's bindings are requested. When binding functions are registered after creating an instance's bindings, the instance's bindings are out of sync until requested again. If they're never requested, they're never synced.
unregister_binding_functions indexes into binding_data, but only checks that its safe to index into binding_functions. When they're out of sync, indexing fails.
This revision checks that it's safe to index into binding_data.
solves #26796
- ADD `String to_string()` method to Object which can be overriden by `String _to_string()` in scripts
- ADD `String to_string(r_valid)` method to ScriptInstance to allow langauges to control how scripted objects are converted to strings
- IMPLEMENT to_string for GDScriptInstance, VisualScriptInstance, and NativeScriptInstance
- ADD Documentation about `Object.to_string` and `Object._to_string`
- Changed `Variant::operator String` to use `obj->to_string()`
When a singleton library was exposing NativeScript functionality,
the NativeScriptLanguage would attempt to terminate the library at
shutdown.
Since the GDNative module itself handles singleton libraries,
it closes all singleton libraries at shutdown as well. This double free
could cause a crash, since the library referenced would no longer be alive.
The issue is that ResourceFormatLoaderText is a singleton. It was created in a faulty way in
ResourceFormatLoaderNativeScript::load
It was created on the stack, which caused the static singleton pointer to be overwritten. This
causes then segmentation faults if the singleton is used later on.
IMO singleton creation needs to made safer to avoid other similar issues in the future.
Fixes the following GCC/Clang warnings:
```
modules/gdnative/nativescript/nativescript.h:280:37: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:281:37: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:283:42: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:285:38: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:287:38: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:290:45: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
modules/gdnative/nativescript/nativescript.h:291:44: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
```
