[SR-8955] Can't use DispatchWorkItem with a non-escaping block #51460
Labels
access control
Feature → modifiers: Access control and access levels
bug
A deviation from expected or documented behavior. Also: expected but undesirable behavior.
compiler
The Swift compiler in itself
regression
swift 4.2
Comments
|
cc @jckarter,aschwaighofer@apple.com (JIRA User) |
|
@swift-ci create |
|
Repo $ cat SR8955.swift
import Foundation
enum Result<T> {
case error
case t(T)
}
func foo<T>(block: () throws -> T) {
let q = DispatchQueue(label: "Test")
var result: Result<T>! = nil
withoutActuallyEscaping(block) { (block) -> () in
let item = DispatchWorkItem(qos: .unspecified, flags: []) {
do {
result = .t(try block())
}
catch {
result = .error
}
}
q.sync(execute: item)
}
}
foo(block: { return 10}) |
|
Our implementation of the DispatchWorkItem constructor temporarily stores the block in the autorelease pool. The autorelease pool optimization fails the first time around on some architectures so the block really ends up in the autorelease pool and therefore leaks out of the withoutActuallyEscaping block. This can be worked around by inserting a autoreleasepool scope inside of the withoutActuallyEscaping closure. import Foundation
enum Result<T> {
case error
case t(T)
}
func foo<T>(block: () throws -> T) {
let q = DispatchQueue(label: "Test")
var result: Result<T>! = nil
withoutActuallyEscaping(block) { (block) -> () in
autoreleasepool {
let item = DispatchWorkItem(qos: .unspecified, flags: []) {
do {
result = .t(try block())
print("executed block")
}
catch {
result = .error
}
}
q.sync(execute: item)
}
}
}
foo(block: { return 10}) |
|
Fix #19859 |
AnthonyLatsis
added
regression
swift 4.2
access control
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Xcode Version 10.0 (10A255)
Puzzlingly, only reproduces on certain devices
Additional Detail from JIRA
md5: 15e0cca8d472b4dfe08f7a378260204f
Issue Description:
I am currently trying to do something like this (swift 4.1)
This block should not escape in practice because it is sent to the queue with
synchowever swift's local inference rules are not powerful enough to understand my argument. withoutActuallyEscaping used to solve this, however on swift 4.2 this produces at runtimeclosure argument was escaped in withoutActuallyEscaping blockI wondered how you guys solve this, and I checked and found there is an internal I-solmently-swear-I'm-up-to-no-good constructor:
IMO either this constructor should be public API, or there should be some language feature to disable this assert, or the assert should be smart enough to realize this doesn't actually escape (or am I the idiot and it escapes here somehow after all?)
The text was updated successfully, but these errors were encountered: