[PATCH] [Clang Static Analyzer] Bug identification

[Babati Bence]

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


Yes, it is already included in the report, but the bugid has to identify the bugs obviously. The bugid lost its meaning when I have to process some other field from report and add to bugid to get the real unique id. On the other hand, the tools will be much faster if they do not have to process more information from the report to identify the bugs.

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


You right. The fuzzy extra field is not required if the bug type is used  as an extra field, but I think, the checker id is needed in the hash. For example, I have two different checkers, but their bug types are same. When these checkers report to same position, then we cannot differentiate between these bugs without checker id.

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


I think, with symbolic execution based checkers this is a good behaviour, but with ast matcher based checkers there could be report multiple bug to the same position which could be a bit annoying. What is your opinion?


http://reviews.llvm.org/D10305

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