Implement more builtin types

[Waridley]

Copied work from the gdext-rust repo as discussed. Still has some TODO's but it should be usable and ready for at least an initial review.

Also prepares for the TypedArray support added by godotengine/godot#65817

[Bromeon]

Hey, thanks a lot for this great PR! It looks mostly good, I had a few questions regarding my understanding.

It's especially cool that you extended the generator for more constructor functions, and in a generic way! Regarding Godot enums/bitfields, I agree the GDNative approach worked relatively well, but we can also evaluate some options (outside this PR).

[Bromeon]

It's probably possible to get 2 Array instances pointing to the same GDScript array, right (e.g. through exported methods later)?

In that case, if you would do

let first: Array = ...;
let second: Array = ...; // same instance

let first_mut = first.get_mut(0);
let second_mut = second.get_mut(0); // aliased &mut -> UB

that creates a soundness hole, no?

If yes, it's fine for me to fix it later, but we might then add it to #5.

[Waridley]

Yeah, that would be a problem... I'm not yet clear on how safety is going to be different from what was done in GDNative. I know sometimes it will be GDScript's responsibility to not break the threading rules, but your example makes it possible to mutably alias just from Rust, which of course should probably be prevented. But then should even immutable access be unsafe just in case a mutable reference gets created on another thread in a similar way?

[Bromeon]

In GDNative, the methods are unsafe, so we "solved" it by telling the user "your problem now" 😁

I see multiple options to address this in the long run:

1. We only give access to values, not references. We could still have utility methods like:

   pub fn replace<F>(&mut self, index: i64, replacer: F)
       where F: FnOnce(Variant) -> Variant

2. We provide reference access, but unsafe. I'm not a big fan of this, as it will just make people write mindless unsafe blocks again, out of performance fear.
3. We coordinate multiple Array instances among each other, and track references, RefCell style. This adds a lot of complexity and overhead though.

[Waridley]

Option 1 seems similar in philosophy to the Entry API in std. Hypothetically we could write our own Entry API for arrays and Dictionaries, but of course that would be more development work. But for every utility function we add, someone else will probably want another one we didn't add 😆 So I would probably want to still expose the unsafe accessors in case someone wants to do something specific, but discourage their use and suggest the utility functions instead.

[Waridley]

Also, for option 1, threads could technically still be problematic.

We may need something like the Shared/Unique types somewhere...

[Bromeon]

Option 1 seems similar in philosophy to the Entry API in std. Hypothetically we could write our own Entry API for arrays and Dictionaries, but of course that would be more development work.

Interesting thought. I'm not opposed to that, but maybe we can plan it for a bit later?

What would we need to have the bare minimum functionality? get() and set() based on values? I'd probably rather do that now than start with unsafe get_ref() methods that we then need to remove 🤔 they're anyway limited in utility, because:

• the one returning &Variant is semantically equivalent to returning Value, so it's mostly an (unsafe) optimization
• the one returning &mut is also not much different from set, because Variant itself is immutable -- so all you could do is assign it directly or via mem::replace(), mem::swap() etc.

Also, for option 1, threads could technically still be problematic.

Unfortunately threads break every single safety assumption we're making, so we'll need the user to opt-in to either not using them or taking responsibility of thread safety themselves. The Unique/Shared model is also just a form of passing the responsibility to the user. It may help in some scenarios, but I'd like to keep the type system simple for now and see how far we get...

[Bromeon]

Thanks for the updates!

Now the whole gdext-builtin/src/macros.rs has changed 😀 is it line endings?
What is your Git configuration of the core.autocrlf flag? I have set it to true on Windows, that should be good, no?

Another option would be to set up rustfmt with newline_style setting, but I prefer if people can use their own line-ending style locally, as long as Git commits it properly. Maybe only for CI or so.

[Waridley]

Thanks for the updates!

Now the whole gdext-builtin/src/macros.rs has changed grinning is it line endings? What is your Git configuration of the core.autocrlf flag? I have set it to true on Windows, that should be good, no?

Another option would be to set up rustfmt with newline_style setting, but I prefer if people can use their own line-ending style locally, as long as Git commits it properly. Maybe only for CI or so.

Mine is set to "input" on linux... Still not sure what happened, but it looks like one of your recent commits fixed it anyway. 🤷‍♂️

Are we planning to automatically drop types that have destructors, or should they only be manually freed? I implemented Drop for StringName in a separate commit to shush a Clippy lint about calling std::mem::forget on it, but I'm not sure if that's the right thing to do or not.

[Bromeon]

Thanks a lot for this! 🚀