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-14720] Mismatched @escaping for closure parameter produces inaccurate diagnostic #57070

Closed
swift-ci opened this issue Jun 3, 2021 · 8 comments

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Jun 3, 2021

Previous ID SR-14720
Radar rdar://problem/79273856
Original Reporter tbw (JIRA User)
Type Bug
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, StarterBug
Assignee @LucianoPAlmeida
Priority Medium

md5: 0bea57816da6c676b14297bdbe7dcf73

Issue Description:

The following program produces the

class A {
    let callback: (() -> Void) -> Void


    init(f: @escaping (@escaping () -> Void) -> Void) {
        self.callback = f
    }
}

following inaccurate diagnostic:

bug.swift:5:23: error: assigning non-escaping parameter 'f' to an @escaping closure
        self.callback = f
                      ^
bug.swift:4:10: note: parameter 'f' is implicitly non-escaping
    init(f: @escaping (@escaping () -> Void) -> Void) {
         ^
            @escaping 

The suggested replacement only worsens the problem.

I would expect to see a message like:

bug.swift:7:23: error: converting non-escaping value to '() -> Void' may allow it to escape
        self.callback = f

which is the one produced by

func f(_: @escaping () -> Void) {}

class A {
    let callback: (() -> Void) -> Void   
   
    init() {
        self.callback = f
    }
}
@typesanitizer
Copy link

@typesanitizer typesanitizer commented Jun 14, 2021

Reproduces on main @ 88cf178 .

@swift-ci create

@typesanitizer
Copy link

@typesanitizer typesanitizer commented Jun 14, 2021

Thanks for sharing a minimal example!

@xedin
Copy link
Member

@xedin xedin commented Jun 14, 2021

luciano (JIRA User) You might be interested in this one, I think it's just poor detection of the assignment source...

@LucianoPAlmeida
Copy link
Collaborator

@LucianoPAlmeida LucianoPAlmeida commented Jun 15, 2021

Sure, I'll take a look =]

@LucianoPAlmeida
Copy link
Collaborator

@LucianoPAlmeida LucianoPAlmeida commented Jun 19, 2021

I'm not sure, this is the same case of 'converting non-escaping value to '() -> Void' may allow it to escape' because in the example the `f` param is outter function type is escaping, the problem seems some confusion when it sees the inner fn type also with @ escaping. So in my understanding if @ escaping is allowed in this inner parameter position, I would expect this to type check correctly. Just asking to make sure what would be the expected behavior or if I'm missing something...

@xedin
Copy link
Member

@xedin xedin commented Jun 19, 2021

I think the diagnostic here should be about the destination of an assignment (`callback`) instead of source of it - `f`, the fact that there is a mismatch between escapiness in an argument of the function type.

@LucianoPAlmeida
Copy link
Collaborator

@LucianoPAlmeida LucianoPAlmeida commented Jul 1, 2021

Fixed on main by #38117
tbw (JIRA User) Can you please verify on next available snapshot and close? Thanks

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Jul 8, 2021

Comment by Theo Weidmann (JIRA)

Looks good

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants