Problem: Not easy to run all checks and tests locally. Redundant CI
workflows.
Solution: Separate CI into two workflows:
* lint: Lua files (stylua, luals), query files (valid captures,
predicates, directives using tsqueryls), docs
(SUPPORTED_LANGUAGES.md) -- does not need parser installation
* tests: parsers (ABI compatibility), query files (tsqueryls on
Linux/macOS; nvim on Windows), highlight and indent tests (separated
for better readability) -- needs parser installation (but only once)
Switch to https://github.com/nvim-treesitter/highlight-assertions fork
with ABI 15 support.
Run all tests (on Linux and macOS) through `make` (`formatlua`,
`checklua`, `lintquery`, `formatquery`, `checkquery`, `docs`, `tests`),
which downloads and caches all necessary dependencies.
Remove `update-readme` workflow (replaced by lint job on PRs).
Problem: Tracking parser revision in lockfile and allowing override
through the parsers module complicates the code. In addition, only
revision changes are handled robustly, not changes to other installation
info.
Solution: Track parser revision in the parsers module directly. Reload
parser table on every install or update call. Support modifying parser
table in a `User TSUpdate` autocommand.
In Prometheus, label values are treated as strings when used with the
`=` and `!=` operators, and as regular expressions when used with the
`=~` and `!~` operators.
Injecting and then highlighting all label values as regex leads to a
situation where entirely valid **string** label values containing regex
special characters are mistakenly parsed and highlighted as regex. This
results in syntax errors, causing labels to be highlighted incorrectly.
For example, in `foo{bar=~"[a-z]{1,3}"}`, `{` and `}` are regex special
characters, so regex highlighting is expected. However, in
`foo{path="/foo/{id}"}`, `{` and `}` are just part of the string and
have no special meaning, so the whole value should be highlighted as a
string.
This patch captures `::` as `@operator` within
`(unary_typed_expression)` and `(typed_expression)`. These should be the
only two cases that the parser can emit when encountering `::` in the
source, but as a fallback it is still captured as `@punctuation` in all
other cases.
The reasons for capturing `::` as an operator are i) the close relation
with the other type-operators `<:` and `>:` and ii) the fact that it is
treated as an operator by the Julia parser, just like `<:` and `>:`.
I think these have been broken since the query parser update. Basically
the inner node for the string content was preventing injections because
include-children was not set.
- Anchor parameter query. There's no need for multiple indent.align
captures
- Narrow down binary_operator indent.begin. From tree-sitter-r corpus
and highlight tests, this seems to be appropriate.
