<div dir="ltr"><div>Hi!<br><br></div>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. <br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 August 2016 at 17:34, Aditya K via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">




<div dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p><span style="font-size:12pt"> </span><br>
</p>
<div style="color:rgb(0,0,0)">
<div>
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>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.</p>
<p>My implementation would take a YAML file which was generated by the clang static analyzer itself.</p></div></div></div></div></div></div></div></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(0,0,0)"><div><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p><br>
</p>
<p><span style="font-size:12pt">There are several advantages of hashing-based method:</span></p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">1. It helps in tracking the history of reports by tracking just one file.</span><br>
</p>
<p>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.</p>
<p>3. The suppression mechanism can be external to clang (if one choses to do so).</p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">4. The hashing based method is easier to implement and maintainable both for clang
 source and the projects using it.</span><br>
</p>
<p><br>
</p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px"></span></p>
<div>
<p style="font-family:Calibri,Arial,Helvetica,sans-serif,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols;font-size:16px">
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.</p></div></div></div></div></div></div></div></div></blockquote><div>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.  <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(0,0,0)"><div><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><div>
</div>
<div><br>
</div>
<p></p>
I think it will be good to have both kinds of support so that projects would have more flexibility.
<div><br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div>-Aditya</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Regards,<br></div><div>Gábor<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><div style="color:rgb(0,0,0)"><div><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<div><br>
<div style="color:rgb(0,0,0)">
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.<wbr>org</a>> on behalf of p23 power via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Sent:</b> Thursday, August 18, 2016 8:41 PM<br>
<b>To:</b> Gábor Horváth<br>
<b>Cc:</b> Clang Dev<br>
<b>Subject:</b> Re: [cfe-dev] Clang Static Analyzer: False Positive Suppression Support</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Suppress using comments (or pragma):</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div></div>
<div>Suppress using hashes</div>
</div>
</blockquote>
<div><br>
</div>
<div>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 <a href="http://comments.in" target="_blank">comments.in</a> 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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Regards,</div>
<div>Phillip</div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>

</div></div><br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div></div></div>