Clippy reports fail to load if stored in a subdirectory or different file tree

[andrewm-aero]

This line assumes that the clippy report file is stored directly in the directory clippy was run from.

This prevents storing the report out-of-tree or in a subdirectory (e.g. target/).

Ideally, there should be some way to specify the "root" (or just assume the analysis root is the root for all source paths).

If this is not possible, please update the documentation to explicitly state this requirement.

[elegoff]

It should actually be already possible to store and fetch the clippy report(s) from other locations than the root of the project

That is done via the community.rust.clippy.reportPaths analysis parameter , where you can define the report location via either a relative path to the root of your project, e.g target/:
community.rust.clippy.reportPaths=target/my-clippy-report.json
or even an absolute path, e.g
community.rust.clippy.reportPaths=/var/data/my-clippy-report.json

By the way it does not have to be a single report , eg
community.rust.clippy.reportPaths=target/my-first-clippy-report.txt, target/a-second-clippy-report.txt (with a co,mma delimiter) should also work

Let me know if I did not understand your question correctly

[andrewm-aero]

I think there's a miscommunication here, let's do a concrete example.

Let's say we have ./src/main.rs and run clippy while in the ./ directory to generate ./target/report.json and set community.rust.clippy.reportPaths=target/report.json. When the scanner is run from the ./ directory, the plugin expects to find a ./target/src/main.rs file, which, obviously, doesn't exist. This is a consequence of the line of code I linked in the first post, where the plugin roots all paths in the reports to the directory that contains the report.

As such, while its possible to refer to a report in a subdirectory, its not possible to store the report in a subdirectory, as it causes it to resolve the source files incorrectly.

[elegoff]

Thanks so much for the clarification. That is a very good catch and we are able to reproduce the issue.

A fix is indeed needed here because that is a very legit use case

[elegoff]

A PR to fix #66 is now merged on the master branch