Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10018] Compiler crashes when weakfying object on closure declaration #52421

Open
igorcferreira opened this issue Feb 28, 2019 · 4 comments
Open
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@igorcferreira
Copy link

Previous ID SR-10018
Radar rdar://problem/48993798
Original Reporter @igorcferreira
Type Bug

Attachment: Download

Environment

Swift 4.1

Xcode 10.1 (10B61)

macOS 10.14.3

Playground version 5.0 (iOS)

MacBook Pro 15" (2017)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: 4d58da649c7f47a03585801ec11fffa8

Issue Description:

When using the syntax [weak object] in a closure that is created inside another closure, the compiler crashes with the error "Segmentation fault: 11". But, weirdly enough, if you weakfy the object inside the top closure (even if not using it), the compiler stops crashing.

Here is a sample code (extracted from the Playground attached to this report):

import Foundation
import PlaygroundSupport
 
class TestObject {
    let name: String
    
    init(name: String) {
        self.name = name
    }
}
 
class Runner {
    let dispatchQueue = DispatchQueue(label: "Playground.TestQueue", qos: .background)
    let objects: [TestObject]
    
    init(objects: [TestObject]) {
        self.objects = objects
    }
    
    func run() {
        self.objects.forEach({ (object) in
            //: I expect this syntax to work, weakfying the `object` variable before passing to the block,
            //: but it actually causes the compiler to crash with error "Segmentation fault: 11"
            self.dispatchQueue.async { [weak object] in
                print(object?.name ?? "<Nil object>")
            }
            
            //: Weirdly, if you uncomment the code bellow the compiler will stop crashing! :)
            //weak var _: TestObject? = object
        })
    }
}
let runner = Runner(objects: [TestObject(name: "a"), TestObject(name: "b"), TestObject(name: "c"), TestObject(name: "d")])
runner.run()
 
PlaygroundPage.current.needsIndefiniteExecution = true
@belkadan
Copy link
Contributor

No longer crashes in Swift 5 / Xcode 10.2, but I still don't think it's doing the right thing.

<stdin>:24:46: error: type of expression is ambiguous without more context
            self.dispatchQueue.async { [weak object] in
                                             ^~~~~~

Without your second declaration, the forEach argument is a single-expression closure, so type inference happens over the entire expression at once, including the closure body (and its nested single-expression closure). However, there's definitely enough type information here to figure out the right types for everything. @xedin?

Another workaround would be to provide a type for object, i.e. (object: TestObject) in.

@igorcferreira
Copy link
Author

Thanks @belkadan for the update! Indeed, providing the type of the object stops the compiler from crashing.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@xedin
Copy link
Member

xedin commented Dec 5, 2022

This issue has been fixed on main, the snippet from description type-checks successfully because everything is type-checked together now.

@xedin
Copy link
Member

xedin commented Dec 5, 2022

@igorcferreira Please use the latest main branch snapshot to verify and close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants