[feature] Add a way to override rule severities from the CLI

[PaulDance]

⭐ 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 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.

[HerringtonDarkholme]

Thanks for the suggesstion.

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.

It this correct?

[PaulDance]

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.

[HerringtonDarkholme]

Designing this feature involves many factors, I'm trying to list a few existing designs

rerpoting level

This option controls if the CLI should REPORT the issue at all

• eslint: --quiet will suppress all warning
• prettier: not configurable on CLI
• ruff: not configurable on CLI
• clippy: configured by --warn --allow rule by rule on CLI

warning

This option controls how to handle warning. Note, ast-grep has more than two diagnostics of warning and error.

• eslint: --max-warning controls when exit code should be non-zero if there are more than X warnings.--quietsuppresses warning at all.
• prettier: no warning. --check returns non-zero as long as unformatted code was found
• ruff: no warning
• clippy: configured by --warn and friends

fix

This option controls if the exit code should be non-zero if fix happens

• eslint: fixed files are not included in error/warning
• prettier: --write writes directly to file
• ruff: fixed files are not included in error/warning
• clippy: fixed files are not included by default. but --exit-non-zero-on-fix can cause Ruff to exit with a status code of 1 if violations were fixed