[cfe-dev] LLVM Dev meeting: Slides & Minutes from the Static Analyzer BoF

[David Blaikie via cfe-dev]

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.

On Mon, Nov 2, 2015 at 4:32 PM, Anna Zaks via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Several people asked me to send out the slides and minutes from the Static
> Analyzer BoF.
>
> Here they are, enjoy!
> Anna.
>
> Slides:
>
>
> Summary of the discussion:
> - 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.
> - Nullability: Compiler warnings based on nullability annotations are
> useful for codebases that utilize annotated APIs. The new nullability
> checker will find even more issues.
> - 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.
> - 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?
> - What about dynamic symbolic execution (tools like Klee)? They are very
> interesting tools. We do not have immediate plans on adopting that approach.
> - Richer annotations: Annotations are great. However, they are only
> effective if they are adopted. Apple frameworks adopted nullability
> annotations. Styling guide + annotations for C++?
> - 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.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151102/cbcb8d46/attachment.html>