> 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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
