<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 24, 2016, at 4:56 PM, p23 power <<a href="mailto:p23power@gmail.com" class="">p23power@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi Anna,</div><br class=""><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 style="word-wrap:break-word" class=""><div class="">The main in-source suppression mechanism that the clang static analyzer supports is the ‘<span style="background-color:rgb(238,238,238)" class="">__clang_analyzer__</span>’ macro. I am not sure if you tried using it or not... so I am curious what are the main limitations of it that you are seeing.<br class=""></div></div></blockquote><div class=""><br class=""></div>The doc page you refer to says: "use this macro to selectively exclude code the analyzer examines" ... so wouldn't this potentially create false positives later in the code path? For example, by excluding code that initializes variables that is required later in the path, the analyzer may then warn about a garbage values.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">Additionally, our customers do not want to, and some times are not allow to, add such annotations into the code, especially when it's maintained by another team or company.<br class=""><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""></div><div class=""> </div><div class="">The static analyzer already has support for suppression hashes in tree. The CodeChecker tool (<a href="https://github.com/Ericsson/codechecker" target="_blank" class="">https://github.com/Ericsson/<wbr class="">codechecker</a>) is using them to provide user workflows such as baselining and issue suppression. </div></div></blockquote><div class=""><br class=""></div><div class="">Where I like this tool, it imposes on the developer that all warnings need to viewed through that interface and it also requires the company to setup the tool in the first place. Many developers just want to run the analyzer locally and either view the stdout or html reports. </div></div></div></div></div></blockquote><div><br class=""></div><div>I have found the text output to be not very helpful in understanding typical static analyzer reports — and in some cases actively harmful since an unhelpful report is more likely to be interpreted as a false positive. I view the text output as primarily a mechanism for testing the analyzer.</div><div><br class=""></div><div>I also think a good goal is to eventually get the static analyzer itself out of the business of generating HTML. It seems to me that decisions about the user workflow of how to present/filter/navigate issues are much better implemented outside of clang itself. I agree that it is important to be able to run the analyzer and view reports without setup — but I think we can achieve this without sticking the UI logic in the compiler.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Lastly, you didn't comment on the idea of feeding a yaml/json file containing the issue hashes back into the analyzer for suppression the output. What are your thoughts on this solution?</div></div></div></div></div></blockquote><div><br class=""></div><div>I think the biggest benefit of using a yaml/json file is for issue baselining rather than suppression and I would support incorporating this functionality in clang for that purpose. It is important that the format be easily diffable and stored in version control — i.e. not sqlite database.</div><div><br class=""></div><div>In my view, the key different between baselining and suppression is that suppressions typically have lifecycle comments associated when them. These comments often include:</div><div>- A justification for the suppression. This is typically an explanation of why the diagnostic is a false positive.</div><div>- A criterion for when the suppression can be removed. This is often in the form of a bug filed against the static analyzer to fix the false positive or a bug filed against the codebase under analysis to follow proper coding conventions (e.g., for memory management and ownership).</div><div><br class=""></div><div>Suppression lifecycle comments are important so that when the code in question changes someone can evaluate whether the suppression is still needed and make sure it is not hiding a true positive in the changed codebase. These comments can either be represented in the code itself (in which case the external yaml/json suppressions file would presumably not be needed) or viewed and stored by some external tool like CodeChecker (in which case this suppression/filtering logic is probably better implemented there).</div><div><br class=""></div><div>Devin</div><div><br class=""></div><div><br class=""></div><div><br class=""></div></div></body></html>