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

[Sean Eveson via cfe-commits]

seaneveson added a comment.

> 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.


We want users to be able to take advantage of the new hash when they upgrade to a new version. There may be a large amount of time between the first user(s) to upgrade and the last. On top of this there is no way to identify when all the users have upgraded.

> 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?


For each suppressed warning we will store all of the produced hashes, then the tool can compare any generated hash against the stored hashes.

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




> 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.


I did not consider that the hashes might be used for something other than suppression. In that case, our problem is identifying which hashes to use for suppression and knowing which order to use them in. Do you have any suggestions?


http://reviews.llvm.org/D10305