The checker names are not purely implementation details, because the user refers to them, when determining which checkers she wants to run. I also think that, the plist itself is also an implementation detail: I think the users are not supposed to read them, but consume them with tools.
When you mention location, you mean the environment? In a new snapshot of the source code the locations may differ, and we do not want to show those reports in the comparision that are just relocated. If we identify bugs using messages, once a message changes (because some rewording, or just adding some more information to it), the comparisons will show the reports that have that message as new. I think the checker names are still a bit more stable. I was working on a web viewer for reports generated by the static analyzer. One of the features of the web viewer was, to be able to jump to the documentation of the checker that reported a specific issue. We had several design rules that we wanted to validate, and the checker documentation containd the design rule, to make it easier for developers to mark false positives. Of course it is possible, to generate the links to the documentation based on the message of the report, but it involves more work to both implement and maintain, since one checker can report multiple messages. All in all, we found it useful to have this information in the Plist output, but it is also possible that information is redundant for others. We needed a unique id for the checkers and we used their names. You think that categories should be used as unique IDs? http://reviews.llvm.org/D6841 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
