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

[Gábor Horváth via cfe-commits]

xazax.hun added a comment.

Thank you for the review!

Before committing this I would like to have a policy regarding future changes and document it inside the IssueHash header.
My proposed policy is the following:

- Do not change the calculation of issue hash unless we have a very good reason to do so.
- Every time the way of calculation changes the name of the hash in the plist should be changed (this makes it possible for users to patch clang to generate both old and new hash for those who are relying on the old hash).

I have some questions though:

- Should we require the generation of old hashes once a change is introduced, or should we expect users who rely on old hash to maintain the old hash generation as an out of tree patch?
- The hash calculation WILL change in the near future once we figured out how to identify checkers properly (but I think it will not make sense to rename the hash for this change). For this reason I think we should mark this feature as experimental, until that change is introduced. What is the recommended way, to do that? Generating a comment to the plist? Just adding a comment to the headers? Only mention it in the commit log?

What do you think?


http://reviews.llvm.org/D10305