You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add some kind of ast-grep scan API to enable one to change the severity of activated rules directly from the CLI and only for the current execution, i.e. not to modify the original files, just override one of their values.
An MVP would probably be to change all severities of all rules to a fixed destination one. A more flexible implementation could be to only override the severity of rules that are to a given level, i.e. something akin to Clippy's -W, -A, -D and -F CLI options. An even more complete version would be to have that being also configurable on a per-rule basis, although I'm not sure I see the use case compared to the previous choice.
💻 Use Cases
When using ast-grep in CI, it is often desirable that any detection should make the process exit with a non-zero status code and therefore make the CI step fail so it may be seen. This is for example what is usually done when checking Clippy or Rustdoc with their respective -D warnings.
The current proper approach would be to set the severity to error directly in the rule definition file. However, keeping it so during development time might be bothering as it will mix with true errors, such as compilation ones. Also, it changes the semantic of the detection: a rule might really be just a warning and not an error as it can have false positives for example. Again, Clippy should be a good inspiration for this.
A workaround is to sed -i 's/severity: warning/severity: error/' in CI only before running ast-grep scan. However, it feels a bit hackish and could easily break in the future if things change in either ast-grep or the rule contents.
The text was updated successfully, but these errors were encountered:
To clarify, you are suggesting to have a way to set the severity level of a rule at the command line. Instead of setting the severity level that will make ast-grep scan returns non-zero exit code.
Yes, that was indeed my suggestion. However, yours is another possibility indeed that might be simpler. Mine just seems the most usual when comparing to Clippy, Rustdoc or even C compilers with -Werror.
⭐ Suggestion
Add some kind of
ast-grep scan
API to enable one to change the severity of activated rules directly from the CLI and only for the current execution, i.e. not to modify the original files, just override one of their values.An MVP would probably be to change all severities of all rules to a fixed destination one. A more flexible implementation could be to only override the severity of rules that are to a given level, i.e. something akin to Clippy's
-W
,-A
,-D
and-F
CLI options. An even more complete version would be to have that being also configurable on a per-rule basis, although I'm not sure I see the use case compared to the previous choice.💻 Use Cases
When using ast-grep in CI, it is often desirable that any detection should make the process exit with a non-zero status code and therefore make the CI step fail so it may be seen. This is for example what is usually done when checking Clippy or Rustdoc with their respective
-D warnings
.The current proper approach would be to set the severity to
error
directly in the rule definition file. However, keeping it so during development time might be bothering as it will mix with true errors, such as compilation ones. Also, it changes the semantic of the detection: a rule might really be just a warning and not an error as it can have false positives for example. Again, Clippy should be a good inspiration for this.A workaround is to
sed -i 's/severity: warning/severity: error/'
in CI only before runningast-grep scan
. However, it feels a bit hackish and could easily break in the future if things change in either ast-grep or the rule contents.The text was updated successfully, but these errors were encountered: