• `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.
