[SR-14720] Mismatched @escaping for closure parameter produces inaccurate diagnostic

[swift-ci]

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]

Reproduces on main @ 88cf178 .

@swift-ci create

[typesanitizer]

Thanks for sharing a minimal example!

[xedin]

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

[LucianoPAlmeida]

Sure, I'll take a look =]

[LucianoPAlmeida]

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]

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]

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

[swift-ci]

Comment by Theo Weidmann (JIRA)

Looks good