This is a patch for the following discussion on the mailing list: http://clang-developers.42468.n3.nabble.com/analyzer-Toning-down-invalidations-td4058816.html
The consensus is, while this approach might temporarily increase the false positive rate a bit systems of mutually-canceling bugs are worth untangling.
Most of the extra results are not false positive due to the less invalidation but other reasons, so we could focus on those problems instead of them being hidden.
Another consideration is that we actually introduce a new class of false positives, when a function is doing an offset trickery with fields. I think such functions should have a special annotation to suppress such false positives.
There are a few questions regarding that:
- What should be the spelling of such an annotation?
- How to handle indirect calls? Even if we were in an ideal world where all the callees are annotated, we might not know who the actual callee is (function pointers, virtual calls etc). So what should we do? Less or more invalidation for all indirect calls or have a separate mechanism to let the user define at the call site how to handle a specific call?
Some other ideas from Artem on the mailing list:
- Relaxing the C++ container inlining heuristic, i.e. replacing it with visitor-based suppressions, so that to still enjoy the benefits of inlining. This will also likely to result in less invalidation, but it could have severe effect on how and where we spend our budget (given the complexity of STL implementations for performance tuning).
- It shouldn't be all that hard to model extents of bindings within RegionStore, so that bindings to sub-structures didn't overwrite bindings to super-structures simply because they have the same base region and the same offset. The only problem here is to model extents of *integers* because we don't represent casts as part of SymbolRefs. All other sorts of SVals have well-defined extents (including, say, lazy compound values).