Closed zshipko closed 4 months ago
Awesome work. I've tested this using a Go plugin to call a JS export as a host function and it works great.
I will do more testing with it tonight.. curious if you have any specific paths that you'd like me to focus on?
Thanks for taking a look!
curious if you have any specific paths that you'd like me to focus on?
I think just testing it out is the most helpful
One future improvement worth calling out is the ability to use types like string
or object
in the d.ts
file, which would automatically get converted from an I64
parameter/result. I have started working on that, but it complicates things a little bit so it seems better to get these changes in first.
One future improvement worth calling out is the ability to use types like string or object in the d.ts file, which would automatically get converted from an I64 parameter/result. I have started working on that, but it complicates things a little bit so it seems better to get these changes in first.
This sounds nice!!
__arg_start
is called to push a new call onto the argument stack (a globalVec<Vec<JSValue>>
), then for each argument an arg function like__arg_i32
or__arg_f32
gets called, this pushes the value to the end of the vector at the the top of the stack, then when a function is called it pops the topVec<JSValue>
off of the stack to use as its arguments.__invokeHostFunc_1_1
,__invokeHostFunc_2_1
, ...) , there are too many combinations to allow for any type to be usedHost.invokeFunc0
to call a host function that takes 0 argumentsHost.invokeFunc
andHost.invokeFunc0
determine the number of arguments passed and select the proper__invokeHostFunc_$nparams_$nresults
function to callwasm-opt
instead ofbinaryen
crate