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

[Anna Zaks via cfe-commits]

zaks.anna added a comment.

> Just for the sake of explaining, lets say in 3 subsequent Analyzer releases the hashes are called “hash_1”, “hash_2” and “hash_3”.




> In the first release the suppression tool will record hash_1 to suppress a warning. Some developers will upgrade to the second and third release, where 

>  others may jump straight to the third release. Additionally some developers may temporarily downgrade to the second after upgrading to the third 

>  release. The suppression tool (which may not be upgraded during this period) needs to maintain suppressions between these version 

>  upgrades/downgrades. Also, some developers may upgrade before others, where they all share one repository of suppressions.




> Say there is an issue with hash_1 and two warnings collide; this is fixed by hash_2. When the user upgrades to the 2nd release, the suppression tool will 

>  record hash_2 on top of hash_1. The tool will then suppress using hash_2 if it is present in the plist file, ignoring hash_1. If the user downgrades and 

>  hash_2 is not in the plist file the tool will suppress using hash_1. For this to work the tool needs to know the order in which to look at the hashes.


I still do not understand how your system would work.

If you have multiple users using a bug suppression system, I would design such system using only a single hash version across all users; using a mix seems error prone.. Once all of your users upgrade to a version of the analyzer where a new hash version is available, you upgrade the hash in the database to reflect that.

Let's talk about your example.
You have user1 using hash_version_1 and user2 using hash_version_2. If the second user suppresses an issue and hash_version_2 is used to record that, how will user1 be able to identity that issue?

Also, as I've mentioned before, the newest issue hash would not necessarily be the best.

> This would work for us, although I agree it might be a little confusing. Would issue_hash_<number>_<name> be better? e.g. 

>  "issue_hash_1_content_of _line_in_context".


We could have a list of issue hashes and each item in the list containing type_of_hash, hash_version, hash. However, I am not yet convinced that this complexity is justified.


http://reviews.llvm.org/D10305