Changing severity mapping

[Tsht]

Hello.
Is it possible to change severity mapping ?
For instance, I use this analyzer : config/labels/analyzers/clang-tidy.json
But some checkers are considered lower for us, it would allow to not filter them in clang, but affect them a lower priority.

[bruntib]

Hi,

As for the severity levels we try to apply the following rules:

Critical severity is reserved currently for compilation errors.
High severity checkers indicate actual runtime errors.
Middle severity checkers indicate error-prone issues that are not necessarily causing runtime errors.
Low severity checkers indicate code smells.

I think, there will always be debatable categorizations when both an example and counter example can be given for a checker category in terms of runtime errors. I would say that we should change severity only if they are in an obviously wrong category.

[Tsht]

Ok thanks, for the one I'm looking at it can be considered as good severity regarding this definition.

[jstevens176]

Since severities were moved into the new Checkers table I have implemented the option to override severities for individual reports in my fork. This introduces a dropdown menu similar to the review status modification drop down menu in the report and allows you to select the new severity. This doesn't change the checker severity, only the severity for the individual report (by virtue of keeping the existing severity column in the report and only using it if it has a value, otherwise falling back to the checker value).

Is this something you would be interested in for me to push upstream?

[bruntib]

The concept here is to assign severity to checkers and not reports. For example, we consider a null pointer dereference as high severity issue, no matter in what context it appears. This intention is now reflected in the database schema. The severity column was in Report table so the queries can be simple and fast. Now the queries a little more tricky, since the Checker table has to be joined, and the performance hasn't decreased.
I would say that it is not a goal currently to Introduce a report level severity.
Could you, please, provide an example where overriding the severity of specific reports is useful?
Thank you!

[jstevens176]

In our case we found that a number of indirectly related issues were reported by the SA tools we use as low severity, but when combined the emergent behaviour was such that the overall severity was higher. And thus we added the ability to change the severity of the various reports to higher and could triage issues more effectively.

Another use case we've come across is "This is a high severity item, but it's only deployed internally so it's not as severe as it seems".
Thanks