[PATCH] [Clang Static Analyzer] Bug identification

[Anna Zaks]

> This is not redundant, and I think we should include the file name in the hash, otherwise bugs in copy pasted code-parts, but in different files will have the same ID.


By redundant, I mean that this information is already encoded in the report; even if it's not part of the issue id. I can see this argument go either way. However, if we do decide to include the filename, we would need to change clang/utils/analyzer/CmpRuns.py and the current issue_hash so that it's all consistent.

> > I believe these should be replaced with a bug identifier. The need for #6 highlights that the checker name is not sufficient here. A bug identifier is the most 

> 

> >  logical match for this info.

> 

> 

> This field is meant to differentiate between multiple reports by the exact same checker at the same position (line, column). So in this case only the checker

>  writer can add additional information that can be a differentiator.


My point is that you would not need the extra field if you use bug type instead of checker id. We need an identifier that describes each type of a bug; instead of an identifier for a checker + a fuzzy extra field.

> Should I change to the current implementation to use only the name of the template parameters? For example, T in the previous example.


What do you think? In this particular example, we would want both issues to be uniqued. I am sure we can construct an example where they should not be uniqued; not sure how rare that is. The best way to find out is to run this over a lot of C++ code and get the stats.


http://reviews.llvm.org/D10305

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/