[SR-8482] protocol with init adopted by a NSObject will crash subclass

[swift-ci]

Previous ID	SR-8482
Radar	rdar://problem/43888894
Original Reporter	SolaWing (JIRA User)
Type	Bug

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, RunTimeCrash
Assignee	None
Priority	Medium

md5: 0cc820e84ab809309573584c993f6595

Issue Description:

import Foundation
public protocol Hello {
 init()
}
extension NSObject: Hello{}
class World: NSObject {
 init(arg: Int=0) {
 super.init()
 }
}
World() // Fatal error: Use of unimplemented initializer 'init()' for class 'main.World'

main.swift: 7: 7: Fatal error: Use of unimplemented initializer 'init()' for class 'main.World'
2018-08-07 21:35:12.009333+0800 main[88892:1650048] main.swift: 7: 7: Fatal error: Use of unimplemented initializer 'init()' for class 'main.World'
Process 88892 stopped

• thread Redundant Load Elimination Patches #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  frame #0: 0x0000000100001a5d main`World.init() at main.swift:7
  4 init()
  5 }
  6 extension NSObject: Hello{}
  -> 7 class World: NSObject {
  8 init(arg: Int=0)
  Unknown macro: { 9 super.init() 10 }
  Target 0: (main) stopped.
  (lldb) bt

• thread Redundant Load Elimination Patches #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)

• frame #0: 0x0000000100001a5d main`World.init() at main.swift:7
  frame Redundant Load Elimination Patches #1: 0x0000000100001a73 main`@objc World.init() at main.swift:0
  frame Remove unnecessary unsafeUnwrap calls. #2: 0x0000000100001a93 main`@nonobjc NSObject.init() at main.swift:0
  frame Initial implementation of a @_cdecl attribute to export top-level functions to C #3: 0x000000010000183f main`NSObject.__allocating_init() at main.swift:0
  frame install Foundation via the ninja script and add the test phase for Foundation #4: 0x00000001000017ae main`main at main.swift:13
  frame Only run bindings-build-record on OS X due to test flakiness on Liunx… #5: 0x00007fff52cab015 libdyld.dylib`start + 1
  frame Debug Info: Don't reset the debug scope after leaving the outermost s… #6: 0x00007fff52cab015 libdyld.dylib`start + 1
  (lldb)

Expected behavior:

compiler should report error. like adopt by a swift class

[belkadan]

Hm, you shouldn't even be allowed to adopt that protocol on NSObject, since not all subclasses are guaranteed to have init().

@swift-ci create

[theblixguy]

@belkadan Could we diagnose this in the type checker? Maybe disallow adopting a protocol on NSObject if it has an initialiser requirement?

[belkadan]

That's the intent, yes. It's not about NSObject specifically, though.

[theblixguy]

What would be the correct way to handle this? Do we look at what protocols the superclass conforms to and if it has an init requirement, we ensure the subclass provides that as well?

[belkadan]

All of this should be something that normal protocol checking already does. The task is to figure out why it's not. (Specifically, why is NSObject.init() considered a valid implementation of Hello's requirement if it's not required? Alternately, if it is required, why is World considered to have implemented it?)

[theblixguy]

Hmm I can see that in matchWitness(), we get `test.(file).Hello.init()` as requirement and `ObjectiveC.(file).NSObject.init()` as witness. We don't get `World` as a witness.

[theblixguy]

I might be looking at the wrong place though... I haven't looked at conformance checking yet.

[theblixguy]

It might be something to do in `checkNonFinalClassWitness()` - for example, we emit an error `initializer requirement 'init()' can only be satisfied by a 'required' initializer in non-final class 'Foo'` if I replace `NSObject` with some other random class (like `Foo`). But if we have NSObject, we don't diagnose because the constructor has a clang node.

[belkadan]

Uh oh. That "don't diagnose" thing is only supposed to be the case if the conformance comes from Clang, not if the type comes from Clang. Did we add that because some initializers aren't imported as required and people complained?

(It's not supposed to look at World at all. World is just a subclass and has nothing to do with NSObject's conformance to Hello.)

cc @slavapestov, @DougGregor

[theblixguy]

Probably. There’s a comment inside the function:

“We exempt Objective-C initializers from this requirement because there is no equivalent to 'required' in Objective-C”