* feat: Allow `--instantiation` to generate non-async code.
The goal of this patch is to allow `--instantiation` to generate non-
async code as discussed in
https://github.com/bytecodealliance/jco/issues/245.
First off, this patch updates the `--instantiation` option to receive
a string value instead of a being a switch. The possible values are
`async` (the default) or `sync`. The fact that `async` is the default
value ensures the backward compatibility.
Next, this patch updates the `TranspileOpts::instantiation` field to be
`Option<InstantiationMode>` instead of `bool`. `InstantiationMode` is a
enum with 2 variants: `Async` and `Sync`. The code is updated
accordingly.
Finally, the same patch adds non-async code during the bindgen pass.
Everything is done in one patch in order to be atomic.
Note: `function_bindgen.rs` is updated to improve an error message. It's
helpful when one needs to debug its code.
* test: Allow multiple test files per fixture.
This patch allows one fixture to be tested by multiple test files.
* test: Add the `strings.sync.ts` test.
* chore: Rename and simplify the `instantiate` signature.
`compileCore` becomes `getCoreModule`, and its function type
definition is now `(path: string)` instead of `(path: string, imports:
Record<string, any>)`.
* Support polyfilling multi-memory
Currently JS does not generally support the WebAssembly multi-memory
proposal. Wasmtime will, however, generate adapter modules which use
multi-memory to communicate between components. This means that composed
components are typically not compatible with the transpile process as
they produce a core module that doesn't actually run in any JS runtime.
This commit fixes this issue by adding polyfill support for
multi-memory. Whenever an adapter is produced that uses multi-memory jco
will now rewrite the module such that any references to memory that
isn't at index 0 to be indirected through functions. These imported
functions then operate on the specified memory on behalf of the wasm
itself. This is a horribly slow process because all memory reads/writes
become function calls, but given that the baseline is otherwise "does
not work" it's hopefully a bit better than before.
The end goal here is to work up towards strings between components, but
for now this just gets everything else working with multi-memory such as
transferring lists.
* Fill out comments
---------
Co-authored-by: Guy Bedford <gbedford@fastly.com>
Guy Bedford
Ivan Enderlin
Alex Crichton