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

[Sean Eveson via cfe-commits]

seaneveson added a comment.

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

> The reason I like names more than the numbers is that we may use different solutions for issue hash generation and some users might prefer one over the other. It is not necessarily clear which one is the best. Numbers would obfuscate the heuristic used to produce the hash and the quality of the hash and would be mainly based on the time when the hash was introduced.


Thanks, I understand where you are coming from now.

> > This makes forwards compatibility difficult, since there is no way to predict the names of future hashes

> 

> >  (As far as I understand).

> 

> 

> Can you describe what you are trying to achieve?


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.

> We can agree that all issue hashes start with "issue_hash" prefix. If you find an entry with "issue_hash" prefix and unknown suffix, you would know that it's new. It would be the same as a number you have not seen so far.


The tool would not be able to establish the order of multiple produced hashes when it was first run.

> > A third alternative would be to have both semantic names (containing hash) and a number suffix

> 

> >  which indicates the ordering.

> 

> 

> If there is a minor enhancement to the existing issue hash method, appending the version number to it is fine by me. Though, this might be confusing in it's own right..


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


http://reviews.llvm.org/D10305