<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi folks,<div class=""><br class=""></div><div class="">@Gabor thank you for opening the conversation, I think it is extremely important!</div><div class=""><br class=""></div><div class="">TBH, at the moment, I am more interested in the first item on the list, so it will be mostly about that item from me.</div><div class=""><br class=""></div><div class="">I want to start off with one common thing for all the items on the list. It is actually something that we should always keep in mind as the top priority, - how easy and pleasant it is to use. If we ask users to add something in their code, it should not look like a gimmick. If it looks elegant and adds value to the code, the users will be happy to add those annotations. In the perfect scenario, it makes code more clear even for users who don’t use the analyzer (one example here is Python and type annotations for Mypy).</div><div class=""><br class=""></div><div class="">So, what’s my take on suppressions (aka item #1). I believe that Aaron’s suggestion is better for two reasons:</div><div class=""><ul class="MailOutline"><li class="">It is more clear in its intentions. From the very first glance you see that this is a suppression.</li><li class="">We already have “suppress” attribute! We just need to adopt it (and maybe add another possible spelling).</li></ul><div class=""><br class=""></div><div class="">However, the hardest choice here is the string argument for the attribute. Again, it would be perfect if we can avoid weird identifiers like “<a href="http://java.com" class="">java.com</a>.warnings.alpha.whatever.2020”, it would be good if that string will make it clear for people who don’t use the analyzer what’s going on here.</div><div class="">Checker names that we use in command line are a bit too verbose, error messages are prone to changes, bug categories are too broad and abstract (the intention is pretty vague if you suppress “Logic error”). </div><div class=""><br class=""></div><div class="">My suggestion would be using so-called “Bug types” (we already show them in the summary table in index.html). Each diagnostic has one, it’s unique and more-or-less descriptive. If we revise all the existing bug types and try to make them concise and clear, I think it can work!</div><div class=""><br class=""></div><div class="">As for other items, summaries… Oof that's a tough one. It looks like we need to parse raw strings anyway, right? So, keeping in mind UX, maybe it should be something entirely different? Something like a DSL specifically for summaries. I don’t have one direct suggestion, but I believe that summaries of all things can be something that all developers can benefit from.</div><div class=""><br class=""></div><div class="">Here is another thought here though. Summaries is not something magical, one summary can not and should not describe the entirety of a particular function. Summaries usually model specific aspects interesting for one particular checker. So one function, can have a good number of checker-specific summaries. It can state that it frees the first argument, dereferences the second argument when the third argument is not equal to 42, and returns tainted data. Expressing everything in one annotation is way too much. Having a bunch of summaries directly in the code can be fine, but can be terrifying (so many lines before the actual function). One way to deal with it is APINotes, but that is a completely different topic.</div><div class=""><br class=""></div><div class="">Honestly, I think the third item is essentially the same thing as summaries, but maybe I don’t see some sort of peculiarity here.</div><div class=""><br class=""></div><div class="">Phew, I got a bit wordy!</div><div class=""><br class=""></div><div class="">Cheers!</div><div class=""><br class=""></div><div class="">Valeriy</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 20 Oct 2020, at 18:38, Gábor Márton <<a href="mailto:martongabesz@gmail.com" class="">martongabesz@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">My example is a bit flawed, so it could look like this:<div class=""><br class=""></div><div class=""><div class="">1) </div><div class="">[[clang::csa("supress.somecheck.somefunctionality")]] void foo();<br class=""></div><div class=""><br class=""></div><div class="">2)</div><div class="">[[clang::csa("summary.BufferSize.Buffer(0).BufSize(1).BufSizeMultiplier(2)")]]<br class=""></div><div class="">std::size_t fread( void* buffer, std::size_t size, std::size_t count, std::FILE* stream );<br class=""></div><div class=""><br class=""></div><div class="">3) </div><div class="">namespace myNamespace {</div><div class="">[[clang::csa("taint.sink")]]</div></div><div class="">void mySink(int x);</div><div class="">} // myNamespace</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 20, 2020 at 5:34 PM Gábor Márton <<a href="mailto:martongabesz@gmail.com" class="">martongabesz@gmail.com</a>> wrote:<br 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 dir="ltr" class="">Hi,<br class=""><div class=""><br class=""></div><div class="">There is an evolving need to configure the Clang Static Analyzer within the analyzed source code itself. We'd like to</div><div class="">1) suppress specific checkers (we already have an ongoing discussion at <a href="https://reviews.llvm.org/D89638" target="_blank" class="">D89638</a>)</div><div class="">2) express summaries (mainly argument constraints)</div><div class="">3) express taint propagation rules for functions (or for global variables like std::cin)</div><div class=""><br class=""></div><div class="">What if we had one attribute for CSA with a StringArgument?<br class="">(Actually, we already have that with the `annotate` attribute.)<br class=""></div><div class=""><br class=""></div><div class="">So we'd have something like this:</div><div class="">1) [[clang::csa("supress.somecheck.somefunctionality")]]</div><div class="">2) [[clang::csa("summary.std::fread.BufferSize.Buffer(0).BufSize(1).BufSizeMultiplier(2)")]]<br class=""></div><div class="">3) [[clang::csa("taint.sink.myNamespace::mySink")]]</div><div class=""><br class=""></div><div class="">Disadvantages: we must process strings whenever a node has the 'csa' attr attached, we have to come up with a "DSL".<br class="">Advantages: total flexibility.<br class=""></div><div class=""><br class=""></div><div class="">I'd like to explore the possible approaches that we could have. For example, Aaron suggested alternatively for the suppression:</div><div class="">[[clang::suppress("analyzer.somecheck.somefunctionality")]]<br class="">[[clang::suppress("compiler.warning.12345")]]<br class="">[[clang::suppress("tidy.check-name.whatever")]]<br class=""></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Gabor</div></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>