when a dockerfile contains several RUN statements, the syntax
highlighting would sometimes run over and encompass dockerfile
statements after the RUN command (typically everything between the first
and last RUN statement, though the bash syntax bleed can be broken by
terminating a RUN statement with a semicolon, or a space 🙄)
we fix this by using a slightly different approach to recognizing /
grouping (the content of) RUN commands:
- instead of having shell_command at the top level of the block we
changed, we're using run_instruction - so parsing happens per `RUN`
statement, which is really what we want
- inseade of `injection.combined`, we use `injection.include-children`,
which combines all the shell fragments (the text parts of a shell
command, including after newline continuations), which is really what
we want, as that's all the text of a RUN statement
that fixes the highlight bleed, and preserves correct highlighting for
each RUN statement.
we also add a regression test for highlighting.
Closes#6530, #6975
* Mark floats as number.float
* Mark function arguments as variable.parameter
* Mark _ placeholder as character.special
* Mark string interpolation delimiters as punctuation.special
Problem: Gitlab has too frequent outages, which break automation.
Solution: Drop all Gitlab-hosted parsers (two of which have been
unmaintained for years).
`trace32_hll_variable` has been removed from the grammar. The
queries are now capturing `symbol` instead. `symbol` is highlighted
as variable or constant.
The majority of jinja variables aren't assigned any highlights at all.
Assign @variable to all identifiers.
Jinja filters without parameters are not highlighted as functions: add a
query for these.
Refine the existing @variable.member to only capture identifiers instead
of broader nodes.
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 `>:`.
