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

[Gábor Horváth via cfe-dev]

Hi!

It is great that there are several implementations lurking around. It is
even better that some people are willing to upstream them. I would be happy
to review them as well. I think other features like not letting suppressed
bugs degrade the coverage can be added later on.

On 19 August 2016 at 17:34, Aditya K via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

>
>
> 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.
>
Having both would be the best for the users. I think comments are more
reliable, but teams sharing the same code or the ability to supppress bugs
in 3rd party code is a strong argument for hashes.


>
> 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.
>
The hash that clang generates for bugs at the moment has the same problem.
It includes some check specific data, like the name of the check. It was
proposed earlier to introduce a unique id for every check that does not
change even when the name or category changes.


>
> I think it will be good to have both kinds of support so that projects
> would have more flexibility.
>
>
> Thanks,
> -Aditya
>

Regards,
Gábor


>
> ------------------------------
> *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 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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160822/616d5ff9/attachment.html>