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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
