More changes for SE-0103 (@noescape by default).

[gonzalolarralde]

The following declarations that were @escaping (default, actually) before SE-0103 and that I think they should remain @escaping.

• dispatch_data_create(…, destructor) along with DispatchData.Deallocator.custom
• dispatch_queue_set_specific(…, destructor) (there's no associated typealias / parameter for this one, it's just being called with Queue._destructDispatchSpecificValue as parameter)

And finally,

• dispatch_source_set_event_handler(…, handler)
• dispatch_source_set_cancel_handler(…, handler)
• dispatch_source_set_registration_handler(…, handler)

along with

• DispatchSourceHandler
• _DispatchBlock

Finally, the rescue parameter in DispatchQueue._syncHelper was marked as @escaping due to a manual migration, but there's nothing keeping a reference to it.

Please let me know if this patch works for you, or if there's anything that needs to be changed. /cc @slavapestov @dgrove-oss

Thanks.

[MadCoder]

that seems wrong, dispatch_sync() takes a dispatch_block_t and is definitely not escaping

[gonzalolarralde]

I get your point, but for what I understand that is a change that should concern the C part of libdispatch. Today dispatch_block_t is being declared in object.h like this:

typedef void (^dispatch_block_t)(void);

and internal typealias dispatch_block_t doesn't seem to be more than a redeclaration of the existing C type. dispatch_block_t is being used both in dispatch_sync and dispatch_async for that matter, that means that it can be both @escaping and @noescape, and from both options @escaping is not the correct, but the safe option.

A different approach may be having a dispatch_noescape_block_t with __attribute__((noescape)), but that will create a difference with the darwin API.

For what I understand here, internal typealias dispatch_block_t is just briging the C type oid (^dispatch_block_t)(void) to the Swift scope, and it's being only used internally.

Am I getting this wrong? What would be the correct solution given the context?

Thanks.

[MadCoder]

my point is that I find it troubling to annotate the type, as if the overlay has to do a

dispatch_sync(q) { ... }

some day for some weird reason, we will get a poorer performance for it. The importer should already have annotated the C functions (that are properly __attribute__((noescape)) where it makes sense) properly already anyway, so I think the one on dispatch_block_t is wrong.

@mwwa do I make sense?

[mwwa]

@gonzalolarralde Does the @noescape (the C markup) from dispatch_sync itself still override the declaration of the block type itself? If so I suspect we're no worse than we were before.

[slavapestov]

Also note that @noescape is now deprecated, and no longer has any functional effect.

[MadCoder]

@MMWa do we have the similar patch for the compiler?
@gonzalolarralde please squash in a single commit

[gonzalolarralde]

@MadCoder Done

[gonzalolarralde]

Based on this swift#4905 and this SR-2444 I will remove @escaping from the optional block, as they're already escaping by default, and there's no way to mark them as no-escape.

The only remaining change will be: src/swift/Queue.swift:238.

[gonzalolarralde]

@maccoder Ok, done! I think the entire thing is probably no longer relevant, as the only change now is that line in that internal method.