Feature request: syntax support for bazelrc files #259
Comments
|
I support this request as well |
|
+1 would also like to see this implemented @adam-azarchs Do you have a draft / overall idea how your PR looks like? |
|
No I don't have a draft; it's not to make a grammar for it but I wasn't going to bother without confirmation that it would be likely to get accepted. Of course I'm talking about a "dumb" grammar file. A smarter one would have a list of known flags and which commands they apply to, which would be neat, but more effort. |
|
Happy to accept a PR. This seems like a good feature. |
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 5, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. The only flag for which it has special treatment is `--config`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 5, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. The only flag for which it has special treatment is `--config`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 5, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. The only flag for which it has special treatment is `--config`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 5, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. The only flag for which it has special treatment is `--config`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 6, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 6, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 7, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 7, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 7, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 7, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 11, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 11, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 11, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does not attempt to handle full bourne-shell quoting semantics. It will only handle quotes around the entire flag, e.g. "--foo=some value" or around the flag value, e.g. --foo="some value" This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags and whether or not the accept a value would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
adam-azarchs
added a commit
to adam-azarchs/vscode-bazel
that referenced
this issue
Apr 16, 2024
The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does not attempt to handle full bourne-shell quoting semantics. It will only handle quotes around the entire flag, e.g. "--foo=some value" or around the flag value, e.g. --foo="some value" This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags and whether or not the accept a value would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. Closes bazel-contrib#259
vogelsgesang
pushed a commit
that referenced
this issue
Apr 17, 2024
feat: syntax highlighting for .bazelrc The main purpose here is really to prevent vscode from autodetecting .bazelrc as a shell file, resulting in complaints about syntax that isn't valid in a bash script, or mistakenly highlighting e.g. variable expansions as if they were actually honored in a .bazelrc. We can also do a bit better, by actually understanding the semantics of e.g. config specifiers and so on. This does not attempt to handle full bourne-shell quoting semantics. It will only handle quotes around the entire flag, e.g. "--foo=some value" or around the flag value, e.g. --foo="some value" This does _not_ try to exhaustively match the list of all possible flags, and so it can make mistakes like treating --copt -O3 as if it were two separate flags rather than a flag + value, however that's mostly harmless. Maintaining a list of known flags and whether or not the accept a value would be prohibitively difficult to maintain without some kind of automation. There is special treatment for a couple of flags, including `--config` and a few flags that expect regex arguments, like `--instrumentation_filter`. The grammar is written in YAML and compiled using `js-yaml` as part of the build process. This requires promoting js-yaml (which was already a transitive dependency) to a direct dev dependency, and adding a line to build.sh to do the conversion. YAML is easier to work with for a number of reasons, especially because (depending on string style used) you don't need to json-escape strings, which is especially helpful for regexes. It also tends to version-control better, and permits adding comments. For testing the bazelrc grammar, this commit adds snapshot test. Closes #259
|
I just open-source https://github.com/salesforce-misc/bazelrc-lsp, in case anyone is interested in giving it a try |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently vscode detects bazelrc files as being shell scripts, which leads to sub-optimal syntax highlighting and also spurious warnings if you have any extensionsenabled (e.g.
shellcheck) which operate on shell scripts.The grammar for bazelrc files seems straightforward, so it seems like it would be fairly trivial to add one in to pick up
.bazelrcorbazelrcfiles. I'm happy to implement this and make a PR if the maintainers are open to it.The text was updated successfully, but these errors were encountered: