
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div><div style="font-size: 14px;" class=""><span style="font-size: 14px;" class=""><br class=""></span></div><font size="4" class="">Summary of the discussion:</font><div class=""><span style="font-size: 14px;" class="">- 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 class="">- 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 class="">- 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 class="">- 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 class="">- What about dynamic symbolic execution (tools like Klee)? They are very interesting tools. We do not have immediate plans on adopting that approach.<br class="">- 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 class="">- 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 class=""><br class=""></div><div class=""><br class=""></div></div></body></html>