Consider using a tool to generate c bindings over manual creation

[jsturtevant]

Right now the api is generated by hand by referencing the wasmtime c library headers. We could automate this process which would make it easier to catch issues and make updates.

See:

Doing a little more digging, and it seems we could use a tool like https://github.com/dotnet/clangsharp?tab=readme-ov-file#generating-bindings to point at header files and generate c#. This would require a bit of changes to the project but would help catch the changes to files.

Originally posted by @jsturtevant in #315 (comment)

[jsturtevant]

I looked into using the generator. The generator takes the approach of doing low level bindings (dotnet/ClangSharp#509 (comment) and dotnet/ClangSharp#427 (comment)).

This requires a slightly different approach and use of unsafe in a few places since it prefers to generate raw pointers over IntPtr and using things like SafeHandle.

As an example, I converted one of the Table calls to the generated bindings:

https://github.com/bytecodealliance/wasmtime-dotnet/compare/main...jsturtevant:wasmtime-dotnet:code-generation?expand=1

I still think there might be value in going this approach so it isn't manual to look up the c api's then map them back to this repo but as you can see with #328 some of the changes are not that difficult.

Going to think on it a bit more and explore how many changes have happened since the last release here (case in point; finding the diffs is one of the harder aspects of the doing this manually). Would love to hear others thoughts as well.

[Hypatech]

This would be great, exposing both unsafe low-level bindings and higher level semantic constructs would be a boon to making this more usable for my needs.

[jsturtevant]

Interesting, I wasn't thinking of this use case (although the binding generator calls this out as one reason for this approach). We don't currently expose those bindings in a public way so would need some changes.

@Hypatech would you mind sharing some more details on your use case?

[Hypatech]

Interesting, I wasn't thinking of this use case (although the binding generator calls this out as one reason for this approach). We don't currently expose those bindings in a public way so would need some changes.

@Hypatech would you mind sharing some more details on your use case?

Gladly!

I really want to be able to use WASM in Unity as a scripting platform for game mods, by offering WIT files for modders to implement new functionality / content.

• If all upstream APIs would quickly be exposed on the low-level layer, I wouldn't have to wait for a C#-ified wrapper. Specifically, I'm waiting for the C API component model to be exposed, but I also understand there will then be additional delay for this to be exposed on the C# side.
• The current marshalled bindings have unnecessary overhead for code that is still functionally unsafe.
• Creating alternate wrappers around these low-level bindings would be much simpler