[SR-2316] typealias for block type not defaulting to @noescape

[swift-ci]

Previous ID	SR-2316
Radar	None
Original Reporter	dgrove-oss (JIRA User)
Type	Bug
Status	Closed
Resolution	Duplicate

Attachment: Download

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: baffa86c07d4e4507700b040d298e309

duplicates:

• SR-2053 [Regression] Using @NoEscape for a type aliased closure results in a compile error

is duplicated by:

• SR-2355 Typealias and escaping
• SR-2493 Escaping and Type-aliases don't work together
• SR-2522 Function attribute @escaping does not apply to function type aliases

Issue Description:

Test case attached. When cleaning up the Dispatch overlay for Linux I observed that a typealias for a closure type did not pick up the default @NoEscape annotation. As a result, the attached test case does not compile (but should).

dgrove@dgrove-vb-swift:~/swift/tests$ swiftc NoEscape.swift 
NoEscape.swift:7:4: error: closure use of non-escaping parameter 'block' may allow it to escape
          block(y)
          ^
NoEscape.swift:4:10: note: parameter 'block' is implicitly non-escaping
func foo(block:(Int)->Void) {
         ^
               @escaping 

[belkadan]

cc @milseman. The actual behavior we want here is that @escaping is a property of the parameter, not the function type, but we don't currently allow you to write @escaping on typealiases. I think there's another JIRA or Radar for that.

[slavapestov]

I thought this was an actual bug, but in fact in TypeCheckType.cpp, we resolve function types differently if they appear inside another function context. This seems inconsistent and weird. It would be better to allow @escaping on type alias types, as Jordan said.

[swift-ci]

Comment by David Grove (JIRA)

The thing that seemed broken to me is that whether a parameter's type is declared with or without using a typealias impacts whether or not the parameter gets the default @NoEscape.

typealias _swift_data_applier = (Int) -> Void
func bogus_error(_ block: _swift_data_applier) { block(10) }
func works_fine(_ block: (Int) -> Void) { block(10) }

The block parameter for bogus_error is considered to be @escaping, but the one for works_fine is considered to be @NoEscape. I would have expected both to be @NoEscape.

[slavapestov]

Yeah, we discussed this today and should have a fix soon. This is definitely a bug.

[swift-ci]

Comment by David Grove (JIRA)

fix confirmed.