```
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.
```
WASI doesn't support `dup(2)` system call, so we cannot implement the
`print_dot_graph` and `print_dot_graphs` functions with exactly the same
semantics as in other platforms.
Previously, `child_containing_descendant` would return `null` when
called on a node's direct parent. In my opinion, this doesn't make much
sense; it seems like a node would contain itself. This (breaking)
commit changes the function so that it can return direct children.
This issue shows up when we have a zero-width token that is the target
descendant node, previously the previous sibling would be returned as
the child that contains the descendant, which is incorrect.
Currently, if a predicate is hard to match on the Rust side, a sizable
query against a very large file can take forever, and ends up hanging.
This commit adds an API function `ts_query_cursor_set_timeout_micros` to
limit how long query execution is allowed to take, thereby negating the
chance of a hang to occur.
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.
The problem is, given an empty file, the root node of this file spans 0
bytes. As such, the logic for determining whether or not the node
precedes the range fails, and is true when it should be false.
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>
