[SR-8482] protocol with init adopted by a NSObject will crash subclass #51003
Comments
|
Hm, you shouldn't even be allowed to adopt that protocol on NSObject, since not all subclasses are guaranteed to have @swift-ci create |
|
@belkadan Could we diagnose this in the type checker? Maybe disallow adopting a protocol on NSObject if it has an initialiser requirement? |
|
That's the intent, yes. It's not about NSObject specifically, though. |
|
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? |
|
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 |
|
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. |
|
I might be looking at the wrong place though... I haven't looked at conformance checking yet. |
|
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. |
|
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 (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.) |
|
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” |
AnthonyLatsis
added
the
crash
Additional Detail from JIRA
md5: 0cc820e84ab809309573584c993f6595
Issue Description:
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
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
unsafeUnwrapcalls. #2: 0x0000000100001a93 main`@nonobjc NSObject.init() at main.swift:0frame 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
The text was updated successfully, but these errors were encountered: