NoQ added a comment.
This problem is fairly complicated. We clearly need both behaviors (sometimes
track until the definition, sometimes track until the collapse-to-null), and
it's not clear to me right now when exactly do we need each of them. This is
also not a high priority for GSoC because neither there are a lot of warnings
of this kind (~15 or so) nor they're actually that false. I suggest taking this
more slowly and delay this patch until we actually understand what is the right
thing to do here.
================
Comment at: clang/test/Analysis/null-deref-path-notes.cpp:20
// expected-note@-1{{Array access (via field 'd') results in a
null pointer dereference}}
- B h, a; // expected-note{{Value assigned to 'h.d'}}
a.d == __null; // expected-note{{Assuming the condition is true}}
----------------
This note was pretty good. It's not very clear but we should definitely keep it.
================
Comment at: clang/test/Analysis/uninit-vals.m:405
int y : 4;
- } a, b, c; // expected-note{{'c' initialized here}}
----------------
These notes are also nice, we should keep them.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62978/new/
https://reviews.llvm.org/D62978
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
