go:wasmexport: unsupported parameter type

[elewis787]

Work is being done in Go 1.24 to support go:wasmexport.

However, there are a handful of unsupported parameter types. The following test shows the supported and unsupported types https://go-review.googlesource.com/c/go/+/611315

*string, and *uint8 are examples I have run into with the current wit-bindgen-go bindings.

Is it a possible solution to use unsafe.Pointer and convert the parameters to their necessary types?

I.e

Breaking

//go:wasmexport count
//export count
func wasmexport_Count(s0 *uint8, s1 uint32, sub0 *uint8, sub1 uint32) (result0 uint32) {
	s := cm.LiftString[string]((*uint8)(s0), (uint32)(s1))
	sub := cm.LiftString[string]((*uint8)(sub0), (uint32)(sub1))
	result := Exports.Count(s, sub)
	result0 = (uint32)(result)
	return
}

Possible workaround

//go:wasmexport count
//export count
func wasmexport_Count(s0 unsafe.Pointer, s1 uint32, sub0 unsafe.Pointer, sub1 uint32) (result0 uint32) {
	s := cm.LiftString[string]((*uint8)(s0), (uint32)(s1))
	sub := cm.LiftString[string]((*uint8)(sub0), (uint32)(sub1))
	result := Exports.Count(s, sub)
	result0 = (uint32)(result)
	return
}

I am still working through a test to ensure this functionality works. I am currently working through the reactor host setup to call the exported function.

[ydnar]

golang/go#66984 fixes this

[elewis787]

golang/go#66984 fixes this

Thanks, I have not seen this yet. I will read through it and follow up. Regardless, would you prefer I close this issue or leave it open until we can confirm the behavior outlined has been implemented/validated?

[ydnar]

Sure, let's leave this open to track.

[prep]

According to the proposal:

Strings are not allowed as result parameters as Wasm practically does not allow more than 1 result parameter.

But when I generate from this:

world test {
    export upper: func(input: string) -> string;
}

It generates this:

//go:wasmexport upper
//export upper
func wasmexport_Upper(input0 *uint8, input1 uint32) (result *string) {

Would it be fair to say this would be in error, even after the proposal is integrated?

[ydnar]

A pointer to a string is a single i32, so it is valid as a return value.

[ydnar]

Is this issue still valid?