r179410 - [analyzer] Makes NewDeleteLeaks checker work independently from NewDelete.

[Jordan Rose]

On Apr 12, 2013, at 15:36 , Anton Yartsev <anton.yartsev at gmail.com> wrote:

> On 13.04.2013 1:52, Jordan Rose wrote:
>> Sorry, I did this deliberately—I wanted NewDeleteLeaks to be a "sub-checker" of sorts, where you couldn't track leaks without also tracking use-after-free issues. Of course, if I really wanted to do that, I should have also made NewDeleteLeaks automatically enable NewDelete, in the same way that they all enable the basic CStringChecker. (Really, only the malloc checkers should do that.)
>> 
>> I guess I should have discussed this with you before slipping it in like this, but do you have an opinion on which way you'd prefer and why? (Can't tell if this is an opinion or just automatically fixing what looked like a mistake.)
> 
> Just automatically fixing. I addressed false-positive leaks and only enabled NewDeleteLeaks. Was surprised that it does not catch anything. Thought it is a bug.
> Should I rollback the commit and add explanatory comment or leave as is for now?


Yes, I think so; adding the code to have NewDeleteLeaks automatically enable NewDelete also makes sense, so that we don't trip over this again and so that the dependency is documented in code.

My particular reason for this is that we already have a number of tests about the interaction between the different pieces of MallocChecker, and I'd like to avoid adding to that configuration matrix. This way, we never have to worry about the case where NewDeleteLeaks is enabled but NewDelete is not, which should help us avoid the problems like what happened with MismatchedDeallocator (Malloc + MismatchedDeallocator = NewDelete!).

Thanks!
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130412/28eb7bc9/attachment.html>