Hi Quentin,

For the MissingDealloc check, yesterday (after reading your comments) I added support in the analyzer to not flag warnings for objects whose ivars are all IBOutlets (please report problems when this doesn't work). This should now be in checker-62 or later (available at http://clang.llvm.org). If anyone has ideas of how the MissingDealloc check can be further improved, please feel free to file a Bugzilla report via the Clang website.

As for the dead stores checker, its purpose is to identify logical mistakes, not penalize legitimate code, so I am completely open to making it smarter to work with different coding idioms. This checker has actually found interesting bugs in code at Apple, with sometimes the check identifying performance bugs and other cases identifying insidious logic errors. From the performance side, although the optimizer in a compiler can optimize away the store itself, it cannot always optimize away the computation used to generate the value that would be stored to the variable. This is particularly the case when the value is computed via Objective-C message expressions; since Objective-C is so dynamic, the compiler takes a conservative approach and typically cannot ever inline the called methods. This means that dead method calls will always be executed, so dead stores can be useful in identifying optimization opportunities for the programmer.

To help address some of your own concerns, in checker-62 I also added support in the analyzer to distinguish between "dead initializations" and "dead stores", which may go part of the way to give you a way to automatically filter some of the false positives for your specific coding idiom. I realize that this may not actually help you for your use of error variables, but in general it should be helpful for users to better triage these bugs. Any suggestions of how to further refine the reporting of dead store bugs to make this check more useful are welcome!

As for reporting more information such as BUGDESC, BUGLINE, etc., we can easily report more information. Please feel free to file Bugzilla reports with such feature requests! We want to make the workflow of using this tool both flexible and fluid, so suggestions of how the workflow can be improved are greatly appreciated. There has also been some mention on the Clang developers' mailing list to potentially support XML output from the analyzer. This would help enable others who wanted to build their own report tracking and presentation infrastructure. This is something that I personally won't have time to work on in the near future, but since the entire tool is open source, anyone who is interested in helping is welcome to do so (more information on the Clang website).