[PATCH] D10305: [Clang Static Analyzer] Bug identification

[Sean Eveson via cfe-commits]

seaneveson added a comment.

We are working on tools that use the new hash for bug suppression. There seems to be no way to predict the names of future hashes. We have products (that will use the bug identification) that are on a different release schedule to our clang compiler. These tools will not be able to take advantage of new hashes, unless they know the future hash names.

Regarding the previous discussions on the hash name:

In http://reviews.llvm.org/D10305#250238, @zaks.anna wrote:

> Maybe we could have "issue_hash", "issue_hash_1"(offset based), and "issue_hash_2"(content of line) and add another field "issue_hash_version" that describes the version "issue_hash" is using?


This would allow tools to discern the order of the hashes from the plist file. It would also be possible to identify new hashes and those that are no longer supported. These are features we would like in order to make our tools as flexible as possible.

In http://reviews.llvm.org/D10305#258162, @zaks.anna wrote:

> I'd suggest to suffix each issue hash field with the description of that hash. For example, we would remove "issue_hash" and replace it with "issue_hash_function_offset" and add "issue_hash_content_of _line_in_context".


This makes forwards compatibility difficult, since there is no way to predict the names of future hashes (As far as I understand).

To resolve the forwards compatibility issues, what are peoples opinions on:

- Having a consistent name with an incrementing number (i.e. issue_hash_1)?
- Adding an ordered list of all the hash names to the plist file?

Regards,
Sean Eveson
SN Systems - Sony Computer Entertainment


http://reviews.llvm.org/D10305