When profiling Dome Keeper, I found that in physics_process a HashMap
gets cleared a lot, which ends up calling the Variant destructor.
Calling Variant::clear() dominates this operation.
By not uselessly setting the Type to NIL on destruction we save about
50% of time. This is likely because if there is a simple type in the
Variant that doesn't need destructing, but now we write when we should
just drop the Variant altogether.
Since the value of Variant::type should be unobservable after
destruction this doesn't change any outward behavior.
This fixes UBSAN errors reported by running our testsuite, importing the
TPS demo, and running the TPS demo. I have tried, wherever possible, to
fix issues related to reported issues but not directly reported by UBSAN
because thse code paths just happened to not have been exercised in
these cases.
These fixes apply only to errors reported, and caused by, core/
The following things have been changed:
* Make sure there are no implicit sign changing casts in core.
* Explicitly type enums that are part of a public API such that users of
the API cannot pass in wrongly-sized values leading to potential stack
corruption.
* Ensure that memcpy is never called with invalid or null pointers as
this is undefined behavior, and when the engine is built with
optimizations turned on leads to memory corruption and hard to debug
crashes.
* Replace enum values only used as static values with constexpr static
const values instead. This has no runtime overhead. This makes it so
that the size of the enums is explicit.
* Make sure that nan and inf is handled consistently in String.
* Implement a _to_int template to ensure that all of the paths use the
same algorhithm, and correct the negative integer case.
* Changed the way the json serializer precision work, and added tests to
verify the new behavior. The behavior doesn't quite match master in
particulary for negative doubles as the original code tried to cast -inf
to an int. This then led to negative doubles losing all but one of
their decimal points when serializing. Behavior in GDScript remains
unchanged.
• `modernize-use-default-member-init` and `readability-redundant-member-init`
• Minor adjustments to `.clang-tidy` to improve syntax & remove redundancies
Variant operators for String formatting and "in" could result in errors, which would return from validated_evaluate without assigning r_ret. This would cause scripts using the return value from these operators to get results from previously run code. Updated to return the original String value in the String formatting case, and false for "in" when an error occurs.
We don't seem to expose any API that uses `char16_t` yet, but I added it anyway since we make the type info for it.
I didn't add anything for `wchar_t` because we are not making a type info so maybe we don't have a need for it yet, it could be added in the future.
To prevent breaking compatibility with the C# bindings, we ignore the `char32_t` metadata and still use `System.Int64`.
C# uses `long`s to access many native values. With `PtrToArg<m_enum>` and
`PtrToArg<bitfield<m_enum>>` this isn't a problem, as C++ code converts
through a `*(int64_t*)` cast in assignment, so all 64-bits are initialized.
However, with `PtrToArg<char32_t>`, value assignment happens through an
`*(int *)` cast, leaving 32 bits uninitialized where `int` is 32 bits. On
platforms where `int` is 16 bits, there are presumably 48 bits uninitialized,
though there are very few platforms where this is still the case.
The easiest way to see the practical effects of this is by looking at
`EventInputKey.Unicode`:
```csharp
public override void _Input(InputEvent @event) {
if (@event is InputEventKey keyEvent) {
if (keyEvent.IsPressed() && !keyEvent.Echo) {
var raw = keyEvent.Unicode;
var value = raw & 0xffffffff;
GD.Print($"Key pressed: raw: {raw}; masked: {(char) value} ({value})");
}
}
}
```
Pressing 'a' emits the following line:
```
Key pressed: raw: -3617008645356650399; masked: a (97)
```
Examining execution flow in gdb shows this conversion going through the
following line:
```
PtrToArg<char32_t>::encode (p_ptr=0x7ffcd5bb4b18, p_val=97 U'a') at ./core/variant/binder_common.h:221
221 *(int *)p_ptr = p_val;
```
Here, `p_val` is still 97, which is the value `InputEventKey.Unicode`
is expected to have. After assignment, `p *(int64_t *)0x7ffcd5bb4b18` displays
`-3617008645356650399`, with only the lower 32 bits being properly assigned,
and is the value we see from C#.
With this patch applied, the above testing `_Input` now prints:
```
Key pressed: raw: 97; masked: a (97)
```
Thank you to blujay1269 for asking about an unexpected value they saw in
`EventInputKey.Unicode`, which prompted this investigation.
This reverts commit 150b50cfcd.
As discussed with the GDScript team, this has some implications which aren't
fully consensual yet, and which we want to revisit.
For now we revert to the 4.2 behavior for the 4.3 release, to avoid breaking
user expectations.
Rémi Verschelde
Thaddeus Crews
Kiro
kobewi
HP van Braam
Yufeng Ying
Pāvels Nadtočajevs
Lukas Tenbrink
Daylily-Zeleen
rune-scape
Danil Alexeev
Rob Mayoff
Hysterelius
Stanislav Labzyuk
A Thousand Ships
Clay John
Yevhen Babiichuk (DustDFG)
Aaron Franke
rune-scape
aaronp64
Slashscreen
Raul Santos
Hilderin
aXu-AP
Danil Alexeev
Haoyu Qiu
Sai Nane
Wilson E. Alvarez
K. S. Ernest (iFire) Lee
kit
Pedro J. Estébanez