Our website uses cookies to enhance your browsing experience.
Your message has been sent. We will email you at
If you do not see the email in your inbox, please check if it is filtered to one of the following folders:
Webinar: Evaluation - 05.12
PVS-Studio can hide repeated warnings. The analyzer allows you to set baseline, which makes it easy to implement static analysis in legacy projects. Should we provide these features for third-party reports?
I decided to write this article after I read some questions on Stack Overflow. Users were asking about how to work with the static analyzer's reports easier. Maybe it makes sense for us to support these third-party reports in PVS-Studio.
At first, I wanted to discuss this question with my teammates at a meeting. But then I realized that the discussion would be abstract without preliminary research of the users' interest in this topic. That's why I'm writing this article — to collect feedback. Comments are much appreciated.
From the very first version, PVS-Studio (ex-Viva64) was able to filter out duplicate messages. It was clear from the very beginning — this is an extremely important functionality if a C or C++ program is analyzed.
I first got acquainted with a static analysis tool in 2006. It was PC-Lint, and I was incredibly annoyed by its reports with endlessly repeating warnings. I don't know much about PC-Lint now, but back then that was the case.
Duplicates occur when linters are triggered by something in the header file. You get an identical warning every time the tool checks a .c/.cpp file that contains this .h header file.
Sometimes the .c/.cpp files have duplicate warnings if the same file is included in different projects of one large solution. This is a rarer scenario, but this is also possible.
When we started developing the first PVS-Studio plugin for Visual Studio 2005, it already hid duplicate messages. All our existing plugins and conversion utilities work the same.
But what do I see when I read Stack Overflow? Questions about removing duplicates! Here's one of the recent discussions as an example: How to avoid duplicate clang-tidy warnings coming from the same header?
Recently I started using clang-tidy in a C++ project and I encountered an annoying problem. When a header contains error and is included in many .cpp files the error is reported multiple times by clang-tidy. Obviously the error is found in different .cpp files, but in fact the error is inside the header and I would like to see just one error message. Is it possible and how could it be done?
BTW: I am aware that a similar question has been asked here. However, the answer is not correct and the problem is not in invoking clang-tidy as a CMake target.
Years have passed but linters still don't provide basic comfort for developers.
I'm not saying it's a serious problem. One can think of lots of ways to fix the situation. For example, you can use SonarQube as a message aggregator. This tool can discard duplicates and generally provides various ways to interact with reports.
Nevertheless, since there are questions on Stack Overflow, then the problem remains.
Another important thing that we did in PVS-Studio — mass suppression of analyzer warnings. It allows to quickly implement the analyzer even in a large project.
The article "How to introduce a static code analyzer in a legacy project and not to discourage the team" describes it all in detail. Here I'll briefly describe the main point.
A user runs the analyzer and gets lots of warnings. Let's say a project that has been developed for many years is tested and brings money. It's unlikely that the analyzer would issue a lot of warnings for such a project. Critical bugs have already been fixed either by more expensive methods or by customers' feedback. Thus, we can consider everything found by the analyzer at the implementation stage as a technical debt. We can fix it gradually, not immediately.
We can tell PVS-Studio to mark these warnings as irrelevant for now (postpone the technical debt), and the analyzer won't show them. The analyzer creates a special file where it stores information about those errors that are currently marked as irrelevant. Starting from this point, PVS-Studio will issue warnings only for new or modified code. Everything's neat here too. For example, if an empty line is added to the beginning of the source code file, the analyzer understands that nothing has changed and will remain silent. The file with information about suppressions can be embedded in the version control system. The file is large, but it's not bad — it's pointless to embed it often.
Now all developers will see warnings related only to new or modified code. Thus, the analyzer can be used almost immediately. And one can return to the technical debt later — gradually correct errors and configure the analyzer.
So, PVS-Studio has worked out the implementation into the project. And what do I see on Stack Overflow? The following question, for example: How to monitor new warnings in code generated by error checking tools?
Do generic tools exist for keeping track of warnings in code?
Some static-analysis tools generate a large number of false-positive warnings, so changing the code isn't desirable. Disabling individual warnings isn't always a practical option either.
Do tools exist that take a list of locations in a file (which could be generated from static analysis tools), which could be run on a regular basis to detect the introduction of new warnings?
Even though diffing the outputs works on a basic level, it would be more useful if changes to line-numbers for example could be done without re-raising the warnings to the developers attention - every time the file was modified.
Yes, our customers can use SonarQube and see what new warnings are issued. And we can think about expanding PVS-Studio's features to support third-party sources of warnings.
We are not going to position ourselves as an alternative to SonarQube. We are thinking of how to simplify the life of developers who already use PVS-Studio. So that they can conveniently work not only with PVS-Studio warnings, but also with third-party warning sources.
By the way, let me remind you that PVS-Studio can be the data source for SonarQube. Read more about it here. So, if you use SonarQube, then it is better to let it aggregate all warnings.
There is a request to filter repetitions in warnings and to track new triggers. We have three options of how we can proceed:
As you understand this article was made to discuss the third option.
What if plugins and conversion utilities included in PVS-Studio worked not only with their own warnings but also with external ones? Would this functionality be useful for you?
Share your opinion in the comments. Thank you.
0
0
0
0