* 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>
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.
Quality of life improvements:
- automatically use `gh auth token` when running `make changelog`
- Add full links to related pull requests
- Include non-conventional commits
- Force group order by adding html comments
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.
* Allow iterations to be specified via an env var
* Randomly decide the edit count, with a maximum
specified via an env var.
* Instead of separate env vars for starting seed + trial, just accept a seed
* Remove some noisy output
The `Emoji` property alias is already present, but the actual property
is not available since it lives in a new file. This adds that file to
the `generate-unicode-categories-json`.
The `emoji-data` file follows the same format as the ones we already
consume in `generate-unicode-categories-json`, so adding emoji support
is fairly easy. his, grammars would need to hard-code a set of
unicode ranges in their own regex. The Javascript library `emoji-regex`
cannot be used because of #451.
For unclear reasons, the characters #, *, and 0-9 are marked as
`Emoji=Yes` by `emoji-data.txt`. Because of this, a grammar that wishes
to use emojis is likely to want to exclude those characters. For that
reason, this change also adds support for binary operations in regexes,
e.g. `[\p{Emoji}&&[^#*0-9]]`.
Lastly (and perhaps controversially), this change introduces new
variables available at grammar compile time, for the major, minor, and
patch versions of the tree-sitter CLI used to compile the grammar. This
will allow grammars to conditionally adopt these new regex features
while remaining backward compatible with older versions of the CLI.
Without this part of the change, grammar authors who do not precompile
and check-in their `grammar.json` would need to wait for downstream
systems to adopt a newer tree-sitter CLI version before they could begin
to use these features.
