<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 16, 2009, at 8:31 PM, Ryan Govostes wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><blockquote type="cite">As an interesting side note, the developers of Adium (<a href="http://www.adiumx.com">http://www.adiumx.com</a>) have actually been regularly scanning their sources using Clang's static analyzer. As part of their process, they wrote some scripts that inspect the emitted diagnostics (in this case HTML files) and did some munging to determine if the a report emitted on a given scan was the same as in a prior scan. Their goal is to avoid re-inspecting previously diagnosed bugs and false positives. Having a general mechanism in the analyzer library would be quite useful, and would be a good first order project for anyone who is interested in getting involved.<br></blockquote><blockquote type="cite"><br></blockquote><br>I thought I'd chime in here; I wrote the scripts we currently use in Adium for this purpose. Sources (which do not work with the latest version of Clang, to my knowledge) are at:<a href="http://trac.adiumx.com/browser/trunk/Utilities/Analyzer">http://trac.adiumx.com/browser/trunk/Utilities/Analyzer</a><br><br>In response to the above paragraphs of Ted's e-mail, I thought I'd announce here that I've been working on a Trac plugin for viewing Clang reports. Recent versions of the analyzer will output to plist files, or HTML files, but not both (though this would presumably be a trivial change). The Trac plugin parses plist files to generate a file view, which is annotated with the appropriate diagnostics.</span></blockquote><div><br></div>That's awesome!</div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Using a dynamic view (i.e., the one generated by Trac) to view the reports has some benefits over the static files. For one, we can strip parts of the code that are irrelevant to the report, instead showing only a few context lines above and below each diagnostic. Another thing we can do is add links to other pages, such as a report generated on a previous revision of the file.</span></blockquote><div><br></div><div>I honestly would like to go to a completely dynamic view model. This was the reason for introducing 'scan-view' to view error reports so that we could eventually move to this model completely. The idea would be (more or less) to generate all error reports as plist files and then use clang on the side to generate syntax-highlighted HTML. This would be far more scalable; it would take less disk space (syntax-highlighted HTML files can get big) and it allows a diversity of rendering of the reports. Of course we still want to support the model where we can get self-contained report files that users can attach to emails, etc., but a dynamic tracking system inherently allows us to do more things: track false positives and bugs across runs, measure interesting statistics, etc.</div><div><br></div><div>I personally think a Trac plugin is a great idea. I would like to see some general infrastructure for building different dynamic interfaces (e.g., the Trac plugin, scan-view) to facilitate the construction of different interfaces that tailor to different tastes/workflows/development processes.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">More importantly, however, is the possibility to automatically file tickets based on new bugs. The system can track a single bug longitudinally across several commits, using simple heuristics to decide when a report has been resolved, or merely changed. (This would integrate well with a system like Buildbot for performing scan builds and uploading new plists.)<br><br>Is there any interest in a plugin like this? I'd be glad to share it on a repository if anyone would like to help flesh out the idea.<br></span></blockquote></div><br><div>I personally wouldn't have much time to work on a Trac plugin, but I would love to see open development on this feature. We can also link to it from the Clang web page. Per my earlier statement, I would like to see some of the logic for tracking issues across runs put into a common library that could be used by multiple interfaces. Some of this logic could be specific to a particular interface (e.g., Trac) while the rest of it would be more generic and reusable.</div></body></html>