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.
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 `>:`.
