
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Another example to help promote your idea:</div><div><br></div><div>I have been working on a static-analyzer checker to detect blocks that capture C++ references to stack variables, however this check only applies for blocks that will execute asynchronously. Currently, I'm implementing the checker to just consider explicit dispatch_async calls, but it would be nice to be able to apply this generally.</div><div><br></div><div>It seems there are four kinds of block execution context:</div><div>* run-once async (ie, dispatch_async, NSOperationQueue:addOperationWithBlock:)</div><div>* run-many async (ie, dispatch timers/sources, xpc_set_event_handler)</div><div><div><div>* sync with another context (eg, dispatch_sync)</div></div></div><div><div>* sync without context change (eg, NSArray:enumerateObjectsWithBlock:)</div></div><div><br></div><div>I'm not sure that's the right set of classifications, but maybe someone on this list can help refine what is the right way to view these objects.</div><div><br></div><div>I do think that a set of annotations for functions that operate with blocks (lambdas too?) would help enable more static analysis checks -- if not also better warnings like the ones you quote.</div><div><br></div><div>Jared</div><br><div><div>On Oct 14, 2013, at 17:31, Michaël Fortin <<a href="mailto:fortinmike@gmail.com">fortinmike@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi there,</div><div class=""><br class=""></div><div class="">I’m new to this mailing list, so let me begin by saying a big thank you to all of the devs working on llvm-clang! The enhancements that were made to Objective-C in the last few years (among other thinks) thanks to your work make our lives much easier.</div><div class=""><br class=""></div><div class="">Now for the actual business: I would like to know if there is currently a way to benefit from the "arc-retain-cycles" warning (Objective-C) for methods that do not begin with “add” and “set”. I’ve checked out the clang source to validate my theory (i.e. that only methods prefixed with “add” and “set” benefit from the check, since I didn’t see any special annotation on the declarations of methods that generated this warning) and from what I’ve seen I was correct (relevant code: SemaChecking.cpp:6634 and the implementation of isSetterLikeSelector() just above that).</div><div class=""><br class=""></div><div class="">I am implementing a few methods in a library that take block arguments and store them for later, repeated execution. However, those methods do not benefit from the arc-retain-cycles warning and it’s pretty easy to create a retain cycle by accident, particularly for novice Objective-C devs. I would like to annotate the methods I know can lead to cycles for inclusion in this check to save others (and myself) from introducing leaks in the future.</div><div class=""><br class=""></div><div class="">If there is a way to do that, I’d love to know how. Else, I’m proposing adding an Objective-C-specific attribute (if that’s the appropriate construct) to indicate that a method’s usages should be checked for potential retain cycles without requiring the method to begin with “add” or “set". Something like:</div><div class=""><br class=""></div><div class="">- (void)doSomethingWithObject:(id)anObject andBlock:(void (^)())aBlock <b class="">__attribute__((check_retain_cycles))</b>;</div><div class=""><br></div><div class="">In addition, it would probably be nice to offer the complementary ability to exclude some “add” and “set”-prefixed methods from the retain cycle check if we know it’s not relevant in a specific case, like the NSOperationQueue “addOperationWithBlock” exclusion that’s currently hard-coded in the isSetterLikeSelector() function (SemaChecking.cpp:6620) but in a dynamic way using an attribute:</div><div class=""><br></div><div class="">- (void)addOperationWithBlock:(void (^)(void))block <b>__attribute__((dont_</b><span class="" style="font-weight: bold;">check_retain_cycles</span><b>))</b>;</div><div class=""><br></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">Best regards,</div><br class=""><div apple-content-edited="true" class="">

<span style="border-collapse: separate; border-spacing: 0px;" class="Apple-style-span"><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;" class="Apple-style-span"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;" class="Apple-style-span"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;" class="Apple-style-span"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;" class="Apple-style-span"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Michaël Fortin</div></span></div></span></div></span></div></span></span></div></div>_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev<br></blockquote></div><br></body></html>