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

[Anton Yartsev]

On 13.04.2013 2:45, Jordan Rose wrote:
>
> On Apr 12, 2013, at 15:36 , Anton Yartsev <anton.yartsev at gmail.com 
> <mailto: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
Committed at r179428.

-- 
Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130413/6413012f/attachment.html>