<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:12.8px">I guess, I should have said “advertised and recommended”, not “documented”. A lot of low-level options are documented in 'clang -help'.</div></blockquote><div> </div><div>Ahh, this is starting to make proper sense. Perhaps it'd be a good idea to note (in help) that certain options aren't intended to be used <i>directly</i>?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:12.8px">Our team has always been careful about not recommending end users to run 'clang —analyze' directly, mainly, because their workflow would stop working if the analyzer ever adds whole program analysis. (Of cause LLVM community knows about the clang option but they are not average end users.)</div><div style="font-size:12.8px"></div></blockquote><div> </div><div>Despite the hard work, I think it's still non-obvious to the average user that they need to use scan-build :(<br></div><div> <br></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8000001907349px">Sincerely,</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">Alexander Riccio</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">--</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">"Change the world or go home."</span><div style="font-size:12.8000001907349px"><a href="http://about.me/ariccio" target="_blank">about.me/ariccio</a></div><div style="font-size:12.8000001907349px"><a href="http://about.me/ariccio" target="_blank"><br></a></div><div style="font-size:12.8000001907349px">If left to my own devices, I will build more.</div><div style="font-size:12.8000001907349px">⁂</div></div></div></div></div></div>
<br><div class="gmail_quote">On Sat, Jan 30, 2016 at 3:13 AM, Anna Zaks <span dir="ltr"><<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div><blockquote type="cite"><div>On Jan 29, 2016, at 9:12 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br><div><br><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Fri, Jan 29, 2016 at 8:32 PM, Anna Zaks via cfe-dev<span> </span><span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jan 29, 2016, at 4:33 PM, Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:</div><br><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">On 01/28/2016 05:53 AM, Aaron Ballman via cfe-dev wrote:</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Thu, Jan 28, 2016 at 2:31 AM, Anna Zaks <<a href="mailto:ganna@apple.com" target="_blank">ganna@apple.com</a>> wrote:<br><snip..><br><blockquote type="cite">This is by design. Many more people have compiler as part of their daily<br>flow so it’s best to have such errors being reported by the compiler.<br>Having the analyzer produce all of the compiler warnings is likely to be too<br>nosy for the users.<br></blockquote>Personally, I find that design to lead to a confusing user experience.<br>When I run the analyzer, my mental model is that I am running the<br>compiler plus some additional analyses. When I don't get compiler<br>warnings that I would otherwise get, it feels like I (as the user)<br>have configured things improperly and done something wrong. Put<br>another way: the point to running a static analyzer is to find out<br>what's wrong with some code, so it's surprising that we would disable<br>some of those notices of what's wrong that would otherwise be enabled<br>by default.<br><br>Perhaps my mental model is in the minority, but it's another anecdote<br>to remember if this design is ever reconsidered again.<br></blockquote><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I'd also find the current design slightly confusing.  I generally don't expect to see *fewer* warnings when I tell the compiler to work harder unless the original warning really was a false positive.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>By calling "$clang —analyze” you are not calling the compiler and asking it to work harder. You are calling another tool that is not going to compile for you but rather provide deep static code analysis. Calling "clang —analyze" could call the compiler behind the scenes and report the compiler warnings in addition to the static analyzer issues. However, when warnings from both tools are merged in a straightforward way on command line, the user experience could be confusing. For example, both tools report some issues such as warning on code like this:</div><div> <span> </span>int j = 5/0; // warning: Division by zero</div><div>                   // warning: division by zero is undefined [-Wdivision-by-zero]</div><div><br></div><div>Most importantly, end users should never invoke the analyzer by calling “clang —analyze” since “clang —analyze” is an implementation detail of the static analyzer. The only documented<span> </span><i>user facing</i> clang static analysis tool is scan-build (see<span> </span><a href="http://clang-analyzer.llvm.org/" target="_blank">http://clang-analyzer.llvm.org</a>).</div></div></div></blockquote></div></div></blockquote><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br></div><div>--analyze is in `clang -help`.</div></div></div></blockquote><br></div></div>I guess, I should have said “advertised and recommended”, not “documented”. A lot of low-level options are documented in 'clang -help'.</div><div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>Also, clang-check advertises a `-analyze` option which was clearly intentionally added.</div></div></div></blockquote><div><br></div></span><div>Is it advertised in places other than help? Again, I do not think we can provide a good user experience for consuming the analyzer results without showing the paths, which 'clang-check' does not do.</div><span><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div> So it seems spurious to say that the only user-facing way to invoke the analyzer is scan-build.</div><div><br></div><div>In fact, anecdotally I seem to remember --analyze as being considered a user-facing option. I'm pretty sure that if I go digging back through old devmtg slides or whatnot I'll find a presentation recommending its use.</div></div></div></blockquote><div><br></div></span>Our team has always been careful about not recommending end users to run 'clang —analyze' directly, mainly, because their workflow would stop working if the analyzer ever adds whole program analysis. (Of cause LLVM community knows about the clang option but they are not average end users.)</div><span><div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>Here are some reasons for that. For one, it is almost impossible to understand why the static analyzer warns without examining the error paths. Second, the analyzer could be extended to perform whole project analysis in the future and "clang —analyze" works with a single TU at a time.</div><div><br></div><div>I agree that the best user experience is to report all warnings in one place, while still differentiating which warning was reported by which tool. It would be awesome if the results from all bug finding tools such as the clang static analyzer, the compiler, and clang-tidy would be reported through the same interface.</div><div><br></div><div>The CodeChecker team is working on a solution for that and I hope we can incorporate their technology in LLVM/clang.</div><div><br></div><blockquote type="cite"><div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Philip</span></div></blockquote></div><br></div><br>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/cfe-dev</a></blockquote></div></div></blockquote></div><br></span></div></blockquote></div><br></div></div>