Skip to content

fix: Separate rules for result keyword with and without <> #84

fix: Separate rules for result keyword with and without <>

fix: Separate rules for result keyword with and without <> #84

Triggered via pull request February 21, 2025 04:06
Status Failure
Total duration 27s
Artifacts

commit-message-lint.yml

on: pull_request
commitlint
14s
commitlint
Fit to window
Zoom out
Zoom in

Annotations

1 error
commitlint
You have commit messages with errors ⧗ input: [fix]: Separate rules for `result` keyword with and without <> fix https://github.com/bytecodealliance/vscode-wit/issues/35 This commit separates the syntax highlighting rules for `result` types with angle brackets (`result<...>`) and `result` types without type parameters. Previously, both types were handled in a single rule, `meta.result.ty.wit`, which ended at a newline (technically "after"), comma, or closing bracket. However, if a `result` type appeared as a parameter, the scope wouldn't end until one of these conditions was met. (As observed, the scope didn’t end even when a newline was encountered, likely because it was captured by other rules, though...). This change simplifies the `meta.result.ty.wit` scope by splitting the handling of `result<...>` and `result`. Now, `result<...>` is handled similarly to `list<...>` and `tuple<...>`, while `result` without `<...>` is handled by `result-base`, which marks the `result` keyword as `entity.name.type.result.wit`. As a consequence of this change, line comments on `result<xxx> // comment` will no longer be ignored. However, this is a known issue for other types as well. ✖ subject may not be empty [subject-empty] ✖ type may not be empty [type-empty] ✖ found 2 problems, 0 warnings ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint