Attribute for "arc-retain-cycles" check in addition to "add" and "set" method selector prefix convention

Hi there,

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.

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).

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.

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:

  • (void)doSomethingWithObject:(id)anObject andBlock:(void (^)())aBlock attribute((check_retain_cycles));

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:

  • (void)addOperationWithBlock:(void (^)(void))block attribute((dont_check_retain_cycles));

What do you think?

Best regards,

Michaël Fortin

Another example to help promote your idea:

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.

It seems there are four kinds of block execution context:

  • run-once async (ie, dispatch_async, NSOperationQueue:addOperationWithBlock:)

  • run-many async (ie, dispatch timers/sources, xpc_set_event_handler)

  • sync with another context (eg, dispatch_sync)

  • sync without context change (eg, NSArray:enumerateObjectsWithBlock:)

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.

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.


Hi Michaël,

If your interest is replicating the current behavior of -Warc-retain-cycles for methods that do not begin with “add” and “set”, then annotations seem like a reasonable ground for experimentation. We’ve done this before with the static analyzer, where it first started with a list of heuristics for identifying methods with specific memory management behavior and then added compiler support for annotations to increase that knowledge base by encoding it in the source code itself. Similarly, having annotations here would be useful, and they could also be useful to disable the builtin heuristic. Such annotations would need to go through design of course, but that could be done via proposing patches and looking at the proposed behavior.

If your interest is to expand the current functionality, that’s a little more involved as it entails more design. Annotations are a small form of language design, and when we add them we need to consider them carefully.