<div dir="ltr">A few of us (from Chris Lattner's example) have committed slide pdfs to www/devmtg/2015-10, if you want to throw them theer too. I guess the assumption is that Tanya will get around to making a tidy webpage for them, along with the videos, when they're all ready.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 4:32 PM, Anna Zaks 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 style="word-wrap:break-word"><div><span style="font-size:14px">Several people asked me to send out the slides and minutes from the Static Analyzer BoF.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Here they are, enjoy!</span></div><div><span style="font-size:14px">Anna.</span></div><div><font size="4"><br></font></div><div><font size="4">Slides:</font></div><div></div></div><br><div style="word-wrap:break-word"><div></div><div style="font-size:14px"><span style="font-size:14px"><br></span></div><font size="4">Summary of the discussion:</font><div><span style="font-size:14px">- IPA: Merging ASTs is not scalable for cross translation unit analysis. Summary approach should be more scalable. Another benefit of the summary approach is that it could support incremental analysis.<br>- Nullability: Compiler warnings based on nullability annotations are useful for codebases that utilize annotated APIs. The new nullability checker will find even more issues.<br>- What is stopping the analyzer from being integrated into clang-tidy/adopted by Google? The analyzer reports are path-sensitive and it is important to see the path for understanding the bugs. There are known limitations of the analyzer that cause false positives on Google code bases; specifically, the handling of temporary C++ objects. We should look into heuristics that could deal with these issues.<br>- Alternate IRGen for better CFG: Correctly modeling temporary objects is hard. We can see that CodeGen is jumping through a lot of hoops to make it work. We would need to repeat a lot of it in the analyzer. This is a problem not only with temporaries but in general due to the analyzer being fed clang ASTs. C++ exceptions not being properly handled by the CFG is another example. We always have to play catch-up with the compiler and add support for new language features. This is hard and takes up a lot of time. Swift went with SIL (Swift Intermediate Language) specifically to solve a very similar problem - allowing analysis and CodeGen to reuse the same IR. (See the SIL talk that Chris L. and Joe G. gave earlier in the day.) This solution would be a lot of work and require a rewrite of both the analyzer and CodeGen. Should we perform static analysis on enriched LLVM IR instead?<br>- What about dynamic symbolic execution (tools like Klee)? They are very interesting tools. We do not have immediate plans on adopting that approach.<br>- Richer annotations: Annotations are great. However, they are only effective if they are adopted. Apple frameworks adopted nullability annotations. Styling guide + annotations for C++?<br>- What are some of the successes of the static analyzer: The analyzer is very effective at intra-procedural analysis. For example, catching manual memory management bugs in Objective-C, misuses of certain APIs.</span><div><br></div><div><br></div></div></div><br>_______________________________________________<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/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>