[cfe-dev] Opinions requested -- nullability analysis in Clang

[George Burgess IV via cfe-dev]

Hello friends!

I've been evaluating the state of null analysis/etc. in clang recently, and
it looks like clang's story for static nullness analysis has been getting
quite a bit better over time. With the help of others, I've identified a
few areas where we may be able to improve, but I'd really like opinions on
whether we think these changes would actually be a good thing.

Specifically, I have four distinct changes in mind:
1. Turn some amount of nullability analysis on by default (with -Wall) in
clang. This would be conceptually *very* similar to uninitialized value
checking, and would be able to catch simple cases like

Foo *p = nullptr;
if (p = getPtr())
  p->oneThing();
else
  p->anotherThing(); // warning: p is null.

...But no promises for any nontrivial cases (without heavily annotated
locals/function signatures ;) ), because there's currently no planned way
to silence the warning if we're somehow wrong.

2. Speaking of nullness annotations, clang supports a lot of them.
Migrating old code to use them could be painful, so having a tool that
annotates obvious things for us may be nice to have
<https://docs.google.com/document/d/1vXuhRTQsbf4F9PbFtCoapuAhCU4RrD-IAiaUfTwp4uA/edit?usp=sharing>
 (
https://docs.google.com/document/d/1vXuhRTQsbf4F9PbFtCoapuAhCU4RrD-IAiaUfTwp4uA/edit?usp=sharing
).

3. Add a CXXRecordDecl-level attribute that instructs nullness analysis to
treat instances of the attributed type as a pointer for the sake of
nullness analysis. This would enable nullness analysis of things like
unique_ptr/shared_ptr/... Doc is available here
<https://docs.google.com/document/d/1Zyb8o210EqkAXxrnrv4XtRu4w_i0yXO04p4KTuTde4M/edit?usp=sharing>
 (
https://docs.google.com/document/d/1Zyb8o210EqkAXxrnrv4XtRu4w_i0yXO04p4KTuTde4M/edit?usp=sharing
).

4. Add clang_tidy checks for missing nullness annotations on function
signatures/global variable decls/member variable decls/...

Like said, any feedback on how {useful,useless} we think these things would
be (and feedback on on the designs themselves) is highly appreciated. :)

Thanks for your time!
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151106/04c4c997/attachment.html>