wit/bindgen: Move wasmimports/wasmexports to a dedicated file

[lxfontes]

Move wasmimport and wasmexport declarations to a dedicated file (named <package>.wasm.go ).

Rationale: The current .wit.go file carries Go and functions intended to be used as wasm bridge ( wasm import / export ). Separating go code from wasm bridge allows readers to identify what is crossing the wasm boundary and gate them if needed. A secondary benefit is paving the way for wit-bindgen-go plugins that utilize the existing ABI and bridge into other implementations. The 2 that come to mind:

1. test/mocking for component unit testing ( with & without wasmtime )
2. networked protocols ( ex https://github.com/wrpc/wrpc )

Sample codegen for wasi:logging

logging.wit.go

//go:nosplit
func Log(level Level, context string, message string) {
	level0 := (uint32)(level)
	context0, context1 := cm.LowerString(context)
	message0, message1 := cm.LowerString(message)
	wasmimport_Log((uint32)(level0), (*uint8)(context0), (uint32)(context1), (*uint8)(message0), (uint32)(message1))
	return
}

logging.wasm.go

// Code generated by wit-bindgen-go. DO NOT EDIT.

package logging

// This file contains all wasmimport/wasmexport functions for "wasi:logging/logging".

//go:wasmimport wasi:logging/logging log
//go:noescape
func wasmimport_Log(level0 uint32, context0 *uint8, context1 uint32, message0 *uint8, message1 uint32)

Edit: a future PR will implement build tags for the <package>.wasm.go file, e.g. //go:build wasm || wasm32 || tinygo.wasm.

[ydnar]

This is great, thanks for drafting the PR. I support this direction.

[ydnar]

FYI, this project follows the Go project conventions for PR names and commit messages:

package: present tense verb describing change

More context...

[ydnar]

One minor change, we could do now or later.

[ydnar]

Do you want to update the PR description to reflect current changes?

[ydnar]

I checked out the branch and ran go test ./wit/bindgen -write, which writes all the generated Go to the filesystem. Afterward, I ran go test ./..., which fails because the wasmimport functions were no longer found.

I think it’s important that go test ./... on Go packages generated by wit/bindgen pass, or at the very least, do not fail.

If the wasm functions are sequestered in a .wasm.go file, how do you think we can accomplish this?

[lxfontes]

I checked out the branch and ran go test ./wit/bindgen -write, which writes all the generated Go to the filesystem. Afterward, I ran go test ./..., which fails because the wasmimport functions were no longer found.

I think it’s important that go test ./... on Go packages generated by wit/bindgen pass, or at the very least, do not fail.

If the wasm functions are sequestered in a .wasm.go file, how do you think we can accomplish this?

It's the //go:build gate on that file.
That's where the wit-bindgen-go --wasmBuildTag was helpful, but could also cause confusion.

I do agree that failing go test is a blocker and think we have 2 options:

• don't add the //go:build part to this PR
• duplicate wasm file, with a build tag negating the wasm file's tags

Duplicating the wasm file doesn't seem to add any value comparing to removing the build tag.
The follow-up PR I was planning is a mock generator for non-wasm builds, performing the lift/lowering into existing structs. That might be a better time to add the //go:build gate to wasm files.

Still have the build tag in the PR and can remove it if that makes sense 👍

[ydnar]

Makes sense to extract the wasm calls into a separate file, without the build tag. That lets us merge this now and solve the related problem later.

[ydnar]

I should have rebased on main before merging, as the type alias PR uncovered a subtle bug in the code that generates Go representation of variant and result types.