[cfe-dev] Future directions for the analyzer

[Ted Kremenek]

On Feb 11, 2014, at 8:20 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> Going a bit further, how do we mark issues as false positives? We have deliberately avoided just copying the diagnostic pragmas, because those aren't necessarily the best interface for the analyzer. Instead, we'd like to come up with some kind of issue tracking, a way to identify an issue across rebuilds. Currently we have a basic implementation of such a thing based on the function the issue was reported in, its position within that function (actually just a relative line number), and the text of the diagnostic. This is clearly less than ideal, but even with that we've had a bit of internal success in comparing analysis results from different revisions of a project—or of the analyzer. (This is where the CmpRuns.py tool comes from, and why it still has that name even though it's become a sort of general-purpose access to the analyzer plists.)

Thanks for the summary Jordan.  I wanted to comment on this point in particular, because the motivation here might not be so apparent to everyone why we want to do things a bit differently for the analyzer than we do for ordinary compiler diagnostics.

With the static analyzer, two factors influence how a particular issue gets reported:

(1) The path the analyzer discovered that led to the issue.

(2) Where along the path the issue should be reported.

Both of these have changed over time, and as we have added richer analysis (e.g., interprocedural analysis within a translation unit) we’ve had a great deal of leeway, and design work, in figuring out the best locations for diagnostics to appear.  We’d like to continue to explore new ways to improve analyzer diagnostics over time, while fundamentally not losing track of a users’s decision to suppress an issue (regardless of whether it is a true positive or a false positive).

Besides desiring flexibility in how issues are reported, we want issue triaging to persist (as much as possible) over code changes.  If a user suppresses an issue and modifies their code, it is possible that the analyzer finds the same problem but along a different code path.  In such cases, the report might even appear in a different location.  Having a flexible triaging system besides pragmas allows us to potentially design solutions that make the analyzer far more tolerant of an evolving codebase.

Finally, users often use the static analyzer with projects that contain a mixture of code that they own, and code borrowed from somebody else.  For example, this could be as simply as using templates from Boost.  An issue from the analyzer may easily span such code boundaries, and users may feel reluctant to sprinkle pragmas (or other source annotations) in the code they don’t directly own.  This same problem can exist with compiler warnings, but it doesn’t usually manifest in quite the same way.  Today we already employ a fair number of heuristics in the analyzer to suppress warnings in contexts where they aren’t that interesting, but ideally we’d want a solution in the long term that is more flexible.  Such flexibility will become more essential as the analyzer gets more sophisticated (e.g., global code analysis).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140211/f004e62f/attachment.html>