Mapping Clippy lints to SonarQube issues

In my current effort to provide a plugin for SonarQube allowing to scan Rust code and import Clippy lints,
I am requesting some feedback about best way to reconcile the Lint levels definition with SonarQube requirements for what it defines as "Issues"
With SonarQube, Issues have two dimensions :

Issue Types

There are three types of issues:

  1. Bug – A coding error that will break your code and needs to be fixed immediately.
  2. Vulnerability – A point in your code that's open to attack.
  3. Codesmell – A maintainability issue that makes your code confusing and difficult to maintain.

Issue Severity

Each issue has one of five severities:

  1. BLOCKER
    Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed.
  2. CRITICAL
    Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed.
  3. MAJOR
    Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ...
  4. MINOR
    Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ...
  5. INFO
    Neither a bug nor a quality flaw, just a finding.

On the other hand there are 4 Lints levels :

  1. allow
  2. warn
  3. deny
  4. forbid

Would a systematic mapping from Lint levels to SonarQube issues make sense in your opinion, e.g
"all Clippy lints with level deny should be imported as SonarQube "Code Smells" with Severity "CRITICAL" etc... ?

If so would you have suggestion about how to map ?

Should the Clippy Lint groups (Correctness Restriction Style Deprecated Pedantic Complexity Perf Cargo Nursery) be (also) considered to define such mapping into SonarQube in your opinion ?

Thanks for your feedback

As far as I can tell almost all of what clippy reports are code smells, which for me doesn't map to critical, rather MINOR or something.

That being said I had clippy find an actual bug in my code once. I kept a RefCell::borrow across an async await point. It compiled fine, but is actually a bug, not a lint and clippy caught it. I feel that was an exception though.

If anything it would be specific lints that can reveal bugs rather than others that really cannot. I think by default they are all set to warn level.

You shouldn't need to care about lint levels, what you actually need to inspect is the level on the output from clippy, I would probably map warning -> MINOR and error -> CRITICAL:

> cargo clippy --message-format json 2>/dev/null | jq 'select(.reason == "compiler-message") | {level: .message.level, message: .message.message}'
{
  "level": "warning",
  "message": "function is never used: `foo`"
}
{
  "level": "error",
  "message": "this comparison involving the minimum or maximum element for this type contains a case that is always true or always false"
}
{
  "level": "error",
  "message": "aborting due to previous error; 1 warning emitted"
}

By using the level you allow developers to configure the lints they care about in their project, Clippy is intended to be used with a handful of #[allow], #[warn] and #[deny] attributes to choose the lints that actually matter for each project.

Clippy has an additional categorization of its lints into one of

  • correctness
  • restriction
  • style
  • deprecated
  • pedantic
  • complexity
  • perf
  • cargo
  • nursery

These could maybe be used for the issue types, correctness is probably a Bug, everything else is a Codesmell, but I don't know any way to see this for the emitted lints other than keeping your own table mapping the lint name to category.

1 Like