```
In file included from tree_sitter/core/lib/src/lib.c:14:
tree_sitter/core/lib/src/./wasm_store.c:868:94: warning: incompatible pointer types passing 'uint32_t *' (aka 'unsigned int *') to parameter of type 'uint64_t *' (aka 'unsigned long long *') [-Wincompatible-pointer-types]
error = wasmtime_table_grow(context, &function_table, lexer_definitions_len, &initializer, &table_index);
^~~~~~~~~~~~
/Users/rpatterson/Projects/amel/py-tree-sitter/.direnv/python-3.11/include/wasmtime/table.h:105:31: note: passing argument to parameter 'prev_size' here
uint64_t *prev_size);
^
In file included from tree_sitter/core/lib/src/lib.c:14:
tree_sitter/core/lib/src/./wasm_store.c:969:102: warning: incompatible pointer types passing 'uint32_t *' (aka 'unsigned int *') to parameter of type 'uint64_t *' (aka 'unsigned long long *') [-Wincompatible-pointer-types]
error = wasmtime_table_grow(context, &self->function_table, dylink_info->table_size, &initializer, &prev_table_size);
^~~~~~~~~~~~~~~~
/Users/rpatterson/Projects/amel/py-tree-sitter/.direnv/python-3.11/include/wasmtime/table.h:105:31: note: passing argument to parameter 'prev_size' here
uint64_t *prev_size);
^
2 warnings generated.
```
This resolves https://github.com/tree-sitter/tree-sitter/issues/3454.
This brings the usage of wasmtime::Engine in line with how wasmtime
intends it to be used. All wasmtime functions that receive an Engine
always receive an `&Engine`, never an owned `Engine`. They are always
responsible for cloning the reference if they need it.
This brings the usage of wasmtime::Engine in line with how TSParser
treats TSLanguages: when setting a language to the parser, the parser is
responsible for cloning the reference to the TSLanguage. It is
counterintuitive for TSParser to have different behavior when receiving
wasmtime_engine_t.
C API users also expect this behavior, see "Memory Management"
[here](https://docs.wasmtime.dev/c-api/wasm_8h.html). Talking about the
C API: without this change, failing to clone the `wasmtime_engine_t`
(which, again, is never something API users need to do in wasmtime) and
then reusing the engine in multiple TSLanguages results in a use after
free. With this change, failing to call `wasm_engine_delete` on your
owned Engine results in a memory leak. Memory leaks are safer than
use-after-free.
Previously, if the last production id in a language did not have
a unique set of fields, the field maps weren't loaded correctly
from wasm.
Co-authored-by: Marshall <marshall@zed.dev>
* In WASM, use a custom, simple malloc implementation that lets us
expicitly reset the heap with a new start location.
* When a WASM call traps or errors, propagate that as a parse failure.
* Reset the WASM heap after every parse.
Co-authored-by: Conrad <conrad@zed.dev>
