Short version: Updates to "mock-with-analysis" [1]: (a) changes to the data model (b) cpychecker support added Longer version: I've been hacking on "mock-with-analysis", my tool for running static code analysis as a side-effect within a regular srpm rebuild (see [1]). I've tweaked the data model (the "firehose" XML format [2]): before, we were outputting one XML file every time an analysis tool found a problem. This approach doesn't capture coverage: we wouldn't know which tools were run on which code. So I've reworked things so that each XML file represents a run of an analysis tool on a source file, and contains zero or more issues (all in a common XML format). It also can contain stats e.g. the wall-clock time of how long the analysis tool on that file. We probably should extend it to capture other metadata like what arguments were passed to GCC (e.g. the -W options). I've also been working on the "cpychecker" analyser [3] that's part of my gcc-python-plugin. This is an analyzer for C code. It looks for common mistakes in usage of the CPython extension API, such as reference-counting bugs. The "firehose" branch of the gcc-python-plugin [4] now uses the firehose Python API as the internal representation format within cpychecker, and can thus "natively" emit XML files in our format, and I've hooked it up in mock-with-analysis so it gets run on all C code. So the mock-with-analysis prototype now has the following run in a mock build: * cppcheck * clang-analyzer * gcc warnings * cpychecker You can see an example of the output here: http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/ As before, it's the results from mock, with a new "static-analysis" directory containing XML result files, and any source files mentioned in the results (grep for "FAKE-GCC" in the build.log to see copious debug spew from the analysis tools). The raw XML results can be seen here: http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/static-analysis/reports/ though most of them are empty (most source files had no issues). To make things slightly easier to read, I wrote a primitive HTML summarizer, and you can see the (ugly) result here: http://fedorapeople.org/~dmalcolm/static-analysis/2013-01-30/python-ethtool-0.7-4.fc19.src.rpm/ugly-summary.html Note though that this output is really just for debugging. (In particular, it's violating my #1 UI requirement, which is that any time I see an analysis report, I want to also see the *code* so that a developer can easily determine if she needs to act on the report - though the sources have been captured - it's just a case of writing a nice UI to this). (Note that this version of cpychecker can emit reports showing a trace of execution needed to reach certain error, and this makes it into the XML - it's just that no such errors were present in this rpm). Next steps are to try running it on more packages, to make things more robust, and to build a good UI (e.g. to present a comparative view of two builds: "what new warnings appeared?" etc). If you're interested in getting involved, I've started making a list of things to try here: https://fedoraproject.org/wiki/StaticAnalysis#Tasks_seeking_volunteers Dave [1] see http://lists.fedoraproject.org/pipermail/devel/2013-January/176872.html and https://github.com/fedora-static-analysis/mock-with-analysis [2] https://github.com/fedora-static-analysis/firehose [3] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html [4] http://git.fedorahosted.org/cgit/gcc-python-plugin.git/log/?h=firehose -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
