Implement Eq and Hash trait methods

[cmcknight-bb]

Hello! Thanks for maintaining this project, it's really been a lifesaver.
I've implemented the Eq and Hash traits, skipping Debug because I'm not aware of a parallel in .NET.
One caveat to note, if Eq is implemented but Hash is not, .NET will show a warning that Object.GetHashCode() should be overwritten as well. If they don't overwrite it, dictionaries/hashmaps and such might not work as expected.

We've been making heavy use of this crate at my org, and this contribution is really an attempt to get my feet wet in the repo with the hope of assisting with the async implementation. Any guidance/warnings on that front would be very appreciated. :)

[arg0d]

Hey, thanks for the contribution. We are really glad to hear this project is making an impact for others!

Regarding the warning for when Eq is implemented, but Hash is not. This seems like a rather advanced use case, I don't have the context in my head to make an informed decision for this. Do you think this should be a harder warning from uniffi-bindgen-cs front? The generator could panic if Hash is not implemented, but if the user knows what he's doing, the panic could be overwritten with a setting in uniffi.toml , e.g. allow_missing_hash_trait: true.

It seems you already have a grasp on the basics of contributing to the project, I'm not sure how I can asist you further. For async, I've attempted an implementation in 0.24 branch, but I've encountered really strange performance issue that I guess is coming from C# runtime itself. Maybe it's something to do with how coroutines are notified in a callback from Rust thread, I'm not entirely sure.

[cmcknight-bb]

I tend to agree that offering guidance on binding generation would be better, but I hesitate because Kotlin has the same Eq/Hash relationship and uniffi-bindgen does not panic or warn in the generator when Hash is missing. C# will warn about it when consuming the .NET bindings and I assume Kotlin would do the same. It seems like the behavior should match the other bindings where the target language support is the same, but I would be happy to add in the panic and setting if it makes more sense for this project.

For async, I'm working through implementing it with the changes made in uniffi-rs v0.25 and I'm hitting the issues called out in your async branch, i.e. performance and needing to marshal pointer return values to IntPtr instead of SafeHandle. The marshalling issue seems pretty straightforward albeit a large-ish change (map FfiType::RustArcPtr to IntPtr and deal with the impact) but I haven't had any revelations about the performance issue unfortunately. I'll keep working on it and hopefully submit a PR soon where we can discuss further. :)

Also just a heads up, I have a set of changes to the local dev scripts that might be useful upstream. I'll PR those soon as well.

[arg0d]

Thanks for making the change, the PR looks good now.

For our use case, it makes sense to detect as many issues as possible during generation. We ship our libraries across Kotlin/Swift/C#/Go/C++, so it's not practical to "test" the bindings after generation. In this setup, any warnings generated by C# compiler are practically useless for library authors, because library authors aren't going to look at compiler logs for 5 different languages. Library authors may not even try to compile the bindings for all 5 languages - they may only test the bindings with Python to ensure library API functionality, and assume that all other language bindings are going to work additional without issues.

I will consult a collague and render my decision about the warning today-ish.

[arg0d]

Actually, in Rust it seems like Eq+Hash also goes hand in hand. If Eq+Hash are usually implemented together in Rust, there is no point to implement this kind of warning for C# generator.