CommonWA was an initial prototype of what turned into the official WASI specification. It seems like tinygo is still using CommonWA. The runtime should probably be adjusted to use WASI, with maybe an optional switch back to CommonWA, if anyone still wants to keep using that.
This is something we will eventually want, certainly. The switch isn't trivial, though: we will need a bit of compiler support because wasi uses a different WebAssembly namespace and LLVM (wasm-ld?) by default puts unknown functions in the env namespace.
It seems like it's just a matter of annotating the function with a "wasm-import-module" attribute in the LLVM IR. https://rust.godbolt.org/z/m0PI1z
Seems like it's mostly a matter of parsing a //go:wasm-import-module xyz here
https://github.com/tinygo-org/tinygo/blob/da857108947aa35ff6e6b5ce16c96359e72fe47c/ir/ir.go#L292
and then similar to here
https://github.com/tinygo-org/tinygo/blob/da857108947aa35ff6e6b5ce16c96359e72fe47c/compiler/compiler.go#L840-L845
use
wasmImportModuleAttr := c.ctx.CreateStringAttribute("wasm-import-module", frame.fn.WasmImportModule)
frame.fn.LLVMFn.AddFunctionAttr(wasmImportModuleAttr)
Yes, something like that will be needed.
I'm busy working on other things right now, but if you could help with such a pragma that would help.
If nobody is working on this, I can maybe give it a try :)
Sure, feel free to work on it. 馃憤
Code that adds //go:wasm-module has now landed in the dev branch.
The //go:wasm-module directive is now part of TinyGo 0.8.0 release.
@CryZe I wonder what's needed next.
We are using WASI now, so I think this issue can be closed. Please reopen if I am mistaken. Thanks everyone!
Most helpful comment
The
//go:wasm-moduledirective is now part of TinyGo 0.8.0 release.