[cfe-dev] Fw: Clang Static Analyzer: False Positive Suppression Support

[Aditya K via cfe-dev]

I had the same confusion while implementing the support for suppressing warnings because different teams would have different preferences. So I decided to implement both.

My implementation would take a YAML file which was generated by the clang static analyzer itself.


There are several advantages of hashing-based method:

1. It helps in tracking the history of reports by tracking just one file.

2. That YAML/JSON file can also be used by any IDEs to display a graphical view of control flow that led to the bug.

3. The suppression mechanism can be external to clang (if one choses to do so).

4. The hashing based method is easier to implement and maintainable both for clang source and the projects using it.


The comment based approach is intrusive to the project and binds the project to clang static analyzer tool in that sense. It is difficult to maintain that functionality in the sense it relies heavily on the format of error report generated by the clang static analyzer. Changing the error category or, moving the checker to another class would require a lot of change in the project. The one big advantage is that this approach enforces very active maintenance of the project.


I think it will be good to have both kinds of support so that projects would have more flexibility.


Thanks,
-Aditya

________________________________
From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of p23 power via cfe-dev <cfe-dev at lists.llvm.org>
Sent: Thursday, August 18, 2016 8:41 PM
To: Gábor Horváth
Cc: Clang Dev
Subject: Re: [cfe-dev] Clang Static Analyzer: False Positive Suppression Support

Hi,

Suppress using comments (or pragma):
Suppress using hashes

At Sony I have had a number of customer requests for this feature, i.e. the analyzer to not output suppressed warnings. My preference is to feed in the hashes to clang, the reason for this is three fold. (1) From an investigation our customers do not want to add suppression's as comments.in<http://comments.in> the source code.  (2) Different teams may want to handle suppression's differently where many teams write/use the same code base (3) A developer may want to suppress everything that is not theirs (only interested in new warnings that they have introduced) whilst the overnight build may want no suppressions (or limited suppressions).  Using the comment/pragma method doesn't allow for configurability in different workflows.

Currently we provide tools that use the hashes stored in a simple json file (and suppress in the report viewer). I was thinking along the lines of passing this json file back into clang.  A json file containing a simple list of hashes is relatively source control friendly, though it is one more file to checkin (i.e. one file to store all hashes per project - obviously developers could decide to do one file per source file too).

I understand that some developers/teams may prefer the comment or pragma option.  Would anybody object to support both methods?  And are you open to using a json file as the input?

Regards,
Phillip


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160819/bd7067a0/attachment.html>