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.
Problem: Allowing undocumented "secret" (sub)captures makes it harder
to write comprehensive colorschemes and catch inconsistent captures.
Solution: Only allow captures listed in CONTRIBUTING.md. Add useful
(cross-language) subcaptures and drop language-specific or too niche
ones.
Follow-up: Adding further `*.builtin` captures and changing queries to
use them.
Language-specific subcaptures should instead be added in user config or
a custom language plugin.
Interpolations (`{{valid js code}}`) and directive attributes
(`<element :directive="valid js code"`) can also be typescript code,
hence we can inject typescript instead of javascript here and still
be ok with highlights (bar some syntax differences between ts and js)
- Consider functions with only one value on the rhs as variables
- Applied composition: `(f . g) <param>` -> `@function.call`
- View patterns
- `@field` in record update expression
- type_tuple and type_list as variables
- quantifier for `exp_apply (<rhs>)+ (variable)`
- type_tuple and type_list as variables
- Treat signatures with only one value on the rhs as variables
(except for `IO a`) -> Fixes#5505.
- Remove redundant anchors from signature function queries.
- Move signature function queries to give them higher priority
- Scoped function types
- Add signature query to function with parameters query
