Ok.  I'm on vacation right now but I plan on removing it soon.  Thank you for 
reporting this issue.

> On Dec 21, 2013, at 1:54 AM, Alexander Kornienko <[email protected]> wrote:
> 
> I found the issue, as we used to turn on all the checkers (except debug ones) 
> in clang-tidy. We have no special interest in this particular checker, so 
> it's fine if you remove it, since it's not fully functional anyway.
> 
>> On 21 Dec 2013 01:21, "Ted Kremenek" <[email protected]> wrote:
>> Alex,
>> 
>> Are you okay with us removing this checker?  It’s never been fully 
>> productized, and has many issues.  For one, it can produce false positives 
>> because the analysis path engine is unsound, and can prune paths that are 
>> actually reachable.  We also had lots of issues with path coverage, which 
>> made this checker rarely fire on a lot of code.  I think it is worth 
>> investigating again one day, but right now its pretty much stale code.
>> 
>> On Dec 20, 2013, at 4:04 PM, Ted Kremenek <[email protected]> wrote:
>> 
>> > IdempotentOperationsChecker has suffered from several known limitations 
>> > for a while, but the addition of interprocedural analysis has certainly 
>> > compounded the issues.  I had thought about it at the time when we added 
>> > interprocedural analysis, but it never became a pressing action item.
>> >
>> > This checker has been in the alpha state for a couple years now.  Making 
>> > it real is going to take a lot of work beyond just fixing these immediate 
>> > issues.  I think we should just go and remove it entirely.  If we want to 
>> > resuscitate it one day we can.
>> >
>> > On Dec 19, 2013, at 9:02 AM, Jordan Rose <[email protected]> wrote:
>> >
>> >>
>> >> Aha, of course. Unfortunately, this means that the IdempotentOperations 
>> >> checker is even more broken than we thought, because it tries to make 
>> >> claims about inlined functions.
>> >>
>> >> I like the assert, but I don't think perpetuating the brokenness is a 
>> >> good idea. With this fix, any blocks that were in an inlined function 
>> >> will not be considered reachable from a path through the caller, even 
>> >> though they might be. Worse, and independent of this issue, is the fact 
>> >> that within an inlined function we only see one path, and the checker 
>> >> might mistakenly take that to be the only possible path.
>> >>
>> >> If we just throw out inlined functions altogether, it might start making 
>> >> sense, but then you don't get very good coverage.
>> >>
>> >> http://llvm-reviews.chandlerc.com/D2427
>> >
>> > _______________________________________________
>> > cfe-commits mailing list
>> > [email protected]
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to