<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"><span style="font-size:12.8px">Whole-program analysis *is* a reasonably compelling reason for a</span><br style="font-size:12.8px"><span style="font-size:12.8px">separate tool, however I don't think it should drive the design for</span><br style="font-size:12.8px"><span style="font-size:12.8px">the user interface. For instance, Visual Studio does not require</span><br style="font-size:12.8px"><span style="font-size:12.8px">execution of a separate tool to enable their static analysis (which I</span><br style="font-size:12.8px"><span style="font-size:12.8px">believe does whole-program analysis).</span><br></blockquote><div><br></div><div>I believe that VS /analyze does do some whole program analysis, but I can't actually find anywhere that Microsoft says so.</div><div><br></div><div>I think it's largely dependent on annotations, and <a href="https://github.com/ariccio/SALExamples/raw/master/5_StaticAnalysisPREfast.pdf">slide 23 of this presentation</a> seems to agree with that.</div><div><br></div><div>As a sidenote, I'm guessing that whole program analysis will need to distil information about individual functions into something conceptually similar to SAL (albeit machine, not human readable) so that the analyzer only needs to move "abstract behavior models" (or whatever) across translation units, instead of entire functions. </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"><span style="font-size:12.8px">So, for instance, how do we </span><span style="font-size:12.8px">intend for clang-cl to support the /analyze option?</span><br></blockquote><div><br></div><div>I feel like I raised this issue somewhere else, but it seems like clang-cl just isn't drop-in compatible with /analyze.</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"><span style="font-size:12.8px">When it comes to diagnostics, the easier </span><span style="font-size:12.8px">we can make it on the user to enable the functionality, the greater </span><span style="font-size:12.8px">the chance of users actually using it.</span></blockquote><div><br></div><div>This. It's like security: if it's not on by default, very few people will even try to turn it on. If it's hard to turn on, nobody will. </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"><span style="color:rgb(80,0,80);font-size:12.8px">The CodeChecker team is working on a solution for that and I hope we can </span><span style="color:rgb(80,0,80);font-size:12.8px">incorporate their technology in LLVM/clang.</span></blockquote><div><br></div><div>That <i>does</i> sound fantastic! I should look into it.</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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 9:55 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 29, 2016 at 11:32 PM, Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>> wrote:<br>
><br>
> By calling "$clang —analyze” you are not calling the compiler and asking it<br>
> to work harder. You are calling another tool that is not going to compile<br>
> for you but rather provide deep static code analysis.<br>
<br>
</span>This is not unlike the way clang-tidy works (which also runs the<br>
analyzer!), but clang-tidy still shows compiler diagnostics.<br>
<span class=""><br>
> Calling "clang<br>
> —analyze" could call the compiler behind the scenes and report the compiler<br>
> warnings in addition to the static analyzer issues. However, when warnings<br>
> from both tools are merged in a straightforward way on command line, the<br>
> user experience could be confusing. For example, both tools report some<br>
> issues such as warning on code like this:<br>
>   int j = 5/0; // warning: Division by zero<br>
>                    // warning: division by zero is undefined<br>
> [-Wdivision-by-zero]<br>
<br>
</span>This is unfortunate, but to me it shows that we have duplication of<br>
efforts in our tools. We run into the same general issue with<br>
clang-tidy checks and the compiler, but the goal is to find one home<br>
for that diagnostic functionality and only enable it there. If we have<br>
diagnostics that live in both the compiler and the analyzer, we're<br>
duplicating effort and we should strive to rectify that where<br>
possible. There's likely to be cases where this is harder (such as<br>
division by zero) because you want the diagnostic enabled by default<br>
without requiring the overhead of running path-sensitive checks, but I<br>
think there are ways we can manage that.<br>
<span class=""><br>
> Most importantly, end users should never invoke the analyzer by calling<br>
> “clang —analyze” since “clang —analyze” is an implementation detail of the<br>
> static analyzer. The only documented user facing clang static analysis tool<br>
> is scan-build (see <a href="http://clang-analyzer.llvm.org" rel="noreferrer" target="_blank">http://clang-analyzer.llvm.org</a>). Here are some reasons<br>
> for that. For one, it is almost impossible to understand why the static<br>
> analyzer warns without examining the error paths. Second, the analyzer could<br>
> be extended to perform whole project analysis in the future and "clang<br>
> —analyze" works with a single TU at a time.<br>
<br>
</span>As a counter-example to requiring examining the code paths, the<br>
compiler has thread role analysis diagnostics (among others) that are<br>
also flow-sensitive and it's never been an issue that users must<br>
examine the error paths, so I'm not certain that's a particularly<br>
compelling reason to require a separate tool. Even templates and<br>
macros require a lot of "path" archaeology, and we've found some<br>
excellent ways to surface that from the compiler.<br>
<br>
Whole-program analysis *is* a reasonably compelling reason for a<br>
separate tool, however I don't think it should drive the design for<br>
the user interface. For instance, Visual Studio does not require<br>
execution of a separate tool to enable their static analysis (which I<br>
believe does whole-program analysis). So, for instance, how do we<br>
intend for clang-cl to support the /analyze option? Since we don't<br>
have whole-program analysis currently, it seems like such a feature<br>
could be designed to operate from a compiler flag (for instance, in<br>
conjunction with compilation databases) that is responsible for<br>
spawning off that secondary tool when required. (Note, I think a<br>
similar approach could be used to support running clang-tidy from the<br>
compiler via a command line flag.)<br>
<span class=""><br>
> I agree that the best user experience is to report all warnings in one<br>
> place, while still differentiating which warning was reported by which tool.<br>
> It would be awesome if the results from all bug finding tools such as the<br>
> clang static analyzer, the compiler, and clang-tidy would be reported<br>
> through the same interface.<br>
<br>
</span>I think we are in agreement, but to verify what I think we're agreeing<br>
on: users don't particularly care about the *tool* used nearly so much<br>
as they care about getting the diagnostics themselves. (For instance,<br>
users don't care if it's a parser error, a semantic error, a<br>
path-sensitive error, etc.) When it comes to diagnostics, the easier<br>
we can make it on the user to enable the functionality, the greater<br>
the chance of users actually using it. Based on that, having a single<br>
mechanism the user can invoke to give them diagnostics (such as the<br>
clang driver itself) is something we should strive towards, even if<br>
that means executing different libraries or executables under the hood<br>
(like we do with cc1). Obviously, *reporting* all the diagnostics in a<br>
single place falls naturally out of invocation of a single tool. Does<br>
that agree with what you were saying, or am I misinterpreting?<br>
<span class=""><br>
> The CodeChecker team is working on a solution for that and I hope we can<br>
> incorporate their technology in LLVM/clang.<br>
<br>
</span>That's fantastic! Thank you for the explanations, as well as all the<br>
hard work on this tool.<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br></div>