Fallback to default testing for all queries present in the parser's
queries directory.
For a given query <QUERY>.scm, the test files are searched in
test/<QUERY>/*
Also mimic the output of other test-running subcommands when testing
queries.
Co-authored-by: Thomas Vigouroux <thomas.vigouroux@protonmail.com>
Reimplemented the fix from #2183 to fix building WASM files with Docker
on Windows again. The --workdir argument gives a path inside the Docker
container, so it must use forward slashes regardless of the default path
separator on the host OS.
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.
