This allows users to build parsers without having to run `test` or
`parse` to invoke the compilation process, and allows them to output the
object file to wherever they like. The `build-wasm` command was merged
into this by just specifying the `--wasm` flag.
It's confusing to have tests in two different top-level directories when working between different grammars, and most of them use `test/corpus` which is more fitting, so time to go.
On macOS, this was done by default regardless of what the user wants.
This was also not done on Windows or Linux. Instead, we now provide a
`--open-log` flag to open the log file in the default browser, and it
works on all platforms.
Previously, `tree-sitter build-wasm` had the ability to build WASM
by using docker to pull in an image with a complete emscripten toolchain.
This commit adds the ability to use podman to do the same thing.
Using podman requires two notable changes:
1. Using the fully-qualified image name. Docker defaults to prepending
`docker.io` to the image name, but podman does not.
2. Podman will mount the `/src/` volume as belonging to root unless
`--userns=keep-id` is passed. I think podman's different
volume-ownership is related to podman's daemonless execution and
`--uidmap` functionality, but I'm not 100% sure.
To test, I ran
```sh
script/fetch-fixtures
script/generate-fixtures
script/generate-fixtures-wasm # <- the important one!
```
which worked as well as the docker version.
The `html` highlight function created its own cancellation flag which
conflicts with the Ctrl-c handler set up in the CLI's `main` block
for `tree-sitter highlight`. We can re-use the cancellation flag from
that block to avoid a panic that happens when using `tree-sitter
highlight -H <file>`
thread 'main' panicked at 'Error setting Ctrl-C handler: MultipleHandlers', cli/src/util.rs:31:6
This change also aligns the parameters that `highlight::ansi` and
`highlight::html` take.
Recently I've been pulling a lot of grammars into GitHub's highlighting backend,
replacing legacy language support with tree-sitter highlighting queries.
Our backend systems have a standard set of highlight captures we expect, very
similar to the standard tagging captures we expect. Though end-user applications
are free to choose whatever tagging nomenclature they want, I think it's nice to
include a checking stage that will help us ensure that we know whether a capture
might be recognized or not. It will also help us figure out where we need to
expand our standard set of captures (see #1539).
Replace non-mutating `ts_parser_wasm_store` function with
`ts_parser_take_wasm_store`, which removes and returns the wasm
store, in order to facilitate single ownership.
