I'm seeing false positives on the new check added in D39438 of the following kind:
void foo() { T buf[16]; for (int n = 0; n < 16; ++n) { T *ptr = &buf[n]; dispatch_async(queue, ^{ use(ptr); }); } dispatch_barrier_sync(queue, ^{}); }
In this case, pointer to the local variable buf is captured by a block that goes into dispatch_async, yet it is not a bug because synchronization ensures that this block quits before the variable goes out of scope.
I guess it's kinda similar to the semaphore synchronization case. We could probably add another suppression for functions that contain any dispatch_barrier_async calls. The ideal solution is to delay the warning until checkEndFunction (like the escape-to-global check does) to see if things get synced up until then (of course, once we have scopes we can make it even more fine-grained).
Alexander, do you think we should keep the checker under a flag (not enabled for regular users) until we get a better understanding of what kinds of synchronizations can get on the way? This diff splits your new check into alpha.core.StackAddressAsyncEscape. Or do you already have good quick fixes coming?