<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">CC-ing the patch author!<div><br></div><div>Also, </div><div><br></div><div>Could you split out the ObjC NoCopy + FreeWhenDone change into a separate patch. It does not seem to be directly related to the other changes. Also, I am not 100% sure what changes we are making there. One part is refactoring, however, you've also removed the check for the message calls from the doesNotFreeMemory(). Do we expect any behavior changes from this?</div><div>(Sorry if I've missed something; the patch is getting big.)</div><div><br></div><div>Anna.</div><div><br><div><div>On Mar 5, 2013, at 10:53 PM, Anna Zaks <<a href="mailto:ganna@apple.com">ganna@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Looks good. Thanks for working on this!<br><br>- case OwnershipAttr::Returns:<br>- State = MallocMemReturnsAttr(C, CE, *i);<br>- break;<br>..<br>+ case OwnershipAttr::Returns:<br>+ State = MallocMemReturnsAttr(C, CE, *i);<br>+ break;<br>..<br>Is the indentation the only diff here? If yes, please keep the previous version; most of the case statements are not indented in the llvm/clang codebases. We usually try to keep the patches focused on the problem solved. If cleanup of existing code is necessary, it should go into a separate commit. <br><br>- HelpText<"Check for memory leaks, double free, and use-after-free problems. Assumes that all user-defined functions which might free a pointer are annotated.">,<br>+ HelpText<"Check for memory leaks, double free, and use-after-free problems. Traces memory managed by malloc()/free(). Assumes that all user-defined functions which might free a pointer are annotated.">,<br>This is getting too long.<br><br>Jordan had previously pointed out that you might need to add 'new' and 'delete' to doesNotFreeMemOrKnown. I do not see that changed. Has it been done or is it not necessary?<br><br>Thanks,<br>Anna.<br><br>On Mar 5, 2013, at 6:25 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><br><blockquote type="cite"><br>On Mar 5, 2013, at 5:12 , Anton Yartsev <<a href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>> wrote:<br><br><blockquote type="cite">Attached is the new patch with unix.MismatchedDeallocator and cplusplus.NewDelete splitted from unix.Malloc plus comments addressed and several other improvements.<br></blockquote><br>Awesome. At this point I think this is basically ready to go in. Anna?<br><br>(We need to update SATestBuild.py and lib/Frontend/CompilerInvocation.cpp to enable the "cplusplus" package again.)<br><br><br><blockquote type="cite">+ delete p; // expected-warning{{Memory allocated by operator new[] should be deallocated by operator delete[], not operator delete}}<br></blockquote><br><br>Bikeshedding again on the warning text: do we really need the word "operator" in there? Maybe just putting quotes around the operator name would be good enough:<br><br></blockquote><br>+1<span class="Apple-converted-space"> </span><br>It's best to keep the diagnostics as concise as possible.<span class="Apple-converted-space"> </span><br><br><blockquote type="cite">"Memory allocated by 'new[]' should be deallocated by 'delete[]', not 'delete'".<br><br>That's this part of printAllocDeallocName (which may have been suggested by me):<br><br><blockquote type="cite">+ if (const CXXNewExpr *NE = dyn_cast<CXXNewExpr>(E)) {<br>+ os << *NE->getOperatorNew();<br>+ return true;<br>+ }<br>+<br>+ if (const CXXDeleteExpr *DE = dyn_cast<CXXDeleteExpr>(E)) {<br>+ os << *DE->getOperatorDelete();<br>+ return true;<br>+ }<br></blockquote><br>It looks like there's a function getOperatorSpelling that will get the name without the word "operator". (It makes sense to leave in the "operator" when it appears in an explicit call expr, just not a normal expression or the "expected" case.<br></blockquote><br>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a></div></blockquote></div><br></div></body></html>