Hi, I was recently playing around with a Kotlin implementation for the wit-bindgen tool and here are some things that I noticed to be missing during the process: •

@JsName(name = "exports#string-error")

fails with error

Name contains illegal chars that can't appear in JavaScript identifier

-> however, look like such method name should be valid e.g. in WIT definitions: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#identifiers • Writing to Custom Section of WASM file -> looks like this is needed for component model. TeaVM offers an

@CustomSection

annotation to allow passing data to WASM file (see https://github.com/konsoletyper/teavm/blob/9f349385ec29ced175233cb0c3a247b87719cee[…]main/java/org/teavm/backend/wasm/render/WasmBinaryRenderer.java) is there something similar planned for Kotlin already? • allocated memory is always 8-byte aligned (https://github.com/JetBrains/kotlin/blob/917f64c8939878821f1bad9b6776238d4f09b675/[…]ibraries/stdlib/wasm/src/kotlin/wasm/unsafe/MemoryAllocation.kt). I see the comment that 8 is the maximum alignment in component model abi. Just for my understanding, does this mean, supporting other alignments is just a matter of optimization? -> to me it seems that other alignments should be possible as well, e.g. at least TeaVM implementation is able to handle that https://github.com/bytecodealliance/wit-bindgen/blob/main/crates/teavm-java/src/lib.rs#L2063. • In general, the ScopedMemoryAllocator does not exactly fit to the code generated by wit-bindgen, as it doesn’t allow to free memory in a callback - which seems to be the way the component model handles de-allocation (via a generated method prefixed with

cabi_post_*

) - any chance that there will be an implementation of MemoryAllocator that allows that usage pattern? I think I’ll be able to share the current state soon to better illustrate the shortcomings.

@JsName(name = "exports#string-error")

fails with error

Name contains illegal chars that can't appear in JavaScript identifier

Annotation

@WasmImport("module", "name")

should be used for WIT instead, it doesn’t have such restrictions. We’ll also need to implement corresponding

@WasmExport

Writing to Custom Section of WASM file

I didn’t know about this, thanks. It looks like we need this indeed, but we don’t have it yet.

allocated memory is always 8-byte aligned. … does this mean, supporting other alignments is just a matter of optimization?

Yes.

ScopedMemoryAllocator does not exactly fit to the code generated by wit-bindgen

Indeed. We need to implement realloc function export.

Annotation

@WasmImport("module", "name")

should be used for WIT instead, it doesn’t have such restrictions. We’ll also need to implement corresponding

@WasmExport

Sure, for import I was using

@WasmImport

, but since there currently is no

@WasmExport

I’m using

@ExperimentalJsExport

together with

@JsName

. How much would it take to remove the restriction for

@JsName

in the WASM context as a shortcut? Probably implemented faster than introducing the

@WasmExport

annotation, right? Regarding the TODOs on Kotlin-side (

@WasmExport

, Custom Section & realloc function): should I file an issue on Youtrack or will you create an internal ticket for that?

@Alexander Girke Super interesting stuff, do you plan to submit a PR on wit-bindgen side at some point? Interested to see a prototype when you have something sharable.

@sdeleuze yes, will push the code very soon - for a PR it’s probably too early, since the generated code can not be compiled correctly atm due to the above (CustomSection (can be mitigated in tests) &

@WasmExport/@JsName

restrictions at least) +

wasmparser

crate not supporting GC proposal code. The latter looks like it’s going to be fixed very soon with https://github.com/bytecodealliance/wasm-tools/pull/1022. Regarding kowasm, I’d be happy to contribute if you see anything that I can add there.

Glad to see the work Ivan is doing (he is a colleague) is useful.

Pushed my wit-bindgen experiments here: https://github.com/alxgrk/wit-bindgen Disclaimer: the code it produces should be more or less compile error free (except for the

@JsName

export names), but doesn’t run yet due to missing implementation of GC proposal in

wasmparser

crate (Ivan Mikushin said that he thinks he can complete that in ~1month) and maybe others. Also, memory allocation & de-allocation will probably not work as expected. I tried to stick as close to the TeaVM Java implementation as possible to minimize maintenance later, but of course I don’t know yet if the generated code would actually run correctly. If you want to have a look at generated test code, run

cargo test

in the repository’s root directory & view the files at

target/runtime-tests/{test-case}/kotlin-{test-case}

- currently,

{test-case}

equals one of

smoke

(already free of any compile error because there are no exports),

lists

,

numbers

,

records

or

variants

. Please let me know if you see any obvious issues.