I believe there is a potential bug in SonarQube’s parsing of external clippy reports in its native rust support. While I have been able to get issues loaded from external clippy reports when they come from standalone crates, SonarQube doesn’t appear to be able to match up the file paths for any issues when parsing a clippy report that was generated against a crate in a cargo workspace.
I have found the source for the clippy support online here. I believe the key issue is the assumption/assertion made here is not always correct:
“Clippy diagnostics are relative to the Cargo manifest directory, which might not be the same as the SonarQube project base directory. Therefore, we need to adjust the file path to make it relative to the SonarQube project base directory using the working directory.”
SonarQube is trying to build a path to the issue assuming the manifest_path and span file_name can be combined. This is correct when using a standalone crate, as the file_name is relative to the crate, and the manifest_path points to the Cargo.toml of the crate. This does not appear to be correct when building a crate within a workspace. While the manifest_path will continue to point at the Cargo.toml for the individual crate, the relative file_name within a span will be relative to the root of the workspace, not the crate.
I have attached a minimal reproduction of this issue. In the attached zip you can see a `projecta` which sits within a workspace, and a `projectb` that does not. Within the folders you can see a generated clippy json which shows the differences in the paths (with manually added commentary at the top of the file). The issues in the clippy report of `projectb` would be loadable by SonarQube, but `projecta` would not.
Additionally the online documentation here seems to state that the key to set the path to an external report is `sonar.rust.clippy.reportPaths` but I believe it actually is `sonar.rust.clippyReport.reportPaths` based on testing and the source here.
I don’t have this issue with the community rust plugin, which always assumes the sonar base dir is the root for relative paths, but this doesn’t seem to work in newer versions of SonarQube with integrated rust support.