[cfe-dev] Future directions for the analyzer

[Jordan Rose]

Hi, Alex, hi, cfe-dev. As I mentioned last night, here are some of the things Ted, Anna, and I have talked about as long-term directions for the static analyzer, particularly those that might relate to clang-tidy.

One of the things the recent CheckName patch brought up is how to silence warnings. Today's check names (apart from those in the alpha.* packages) haven't ever been promised to be stable, but we know people are relying on them, so we try not to change them often. Our last pass for cleaning up these names was prompted by the "macosx" -> "osx" rename, but even there we're sort of sidestepping iOS, which hasn't been called "OS X" since 2008. The more interesting thing might be to break down existing checkers further and to come up with a good notion of what constitutes a single "check". Which checkers need to be turned on to implement a particular "check" should be an implementation detail (and mostly already is).

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.)

As you know, currently the only way to silence an unwanted analyzer report is to disable a checker, which can be done on a per-translation-unit basis. To make a long story short, we haven't designed anything else yet, but if/when we do we'd prefer it to be more in line with "issue tracking" rather than "silencing", ("We" here referring to "the LLVM community interested in the analyzer", not just "Apple analyzer folks".)

In the long-term, we've thought about adding a true full-program analysis mode to the analyzer. In this mode, scan-build might really be the primary interface, with "clang --analyze" limited to a single translation unit. The single-TU mode probably isn't going away, and even today most of the checkers operate on a per-function level (most analyzer state is reset between top-level entry points), but there are certainly things that would require cross-TU reasoning, such as Vassil's proposed project-wide copy-paste analysis. Of course, we would be able to expose this functionality in a library (pass a compilation database, analyze everything in it).

All of these things could be interesting for clang-tidy in the future, but likely not in any sort of incompatible way. (More proximally, I'm still wondering how you intend to expose path diagnostics in a meaningful way.) Regardless, it's probably good to write this all down, and yes, I should probably include some of it on the analyzer website.

For now, I think Ted said it well in our offline chat yesterday: getting more people to use the analyzer can only be good for the project. Please continue to send requests and patches our way, and thanks for your patience and understanding of my concerns thus far. Let's make this a good one!

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140211/ce83c743/attachment.html>