[SR-358] Compiler crashes when protocol defines a static method and a conforming class implements it non-statically Created: 23 Dec 2015  Updated: 5 Jan 2016  Resolved: 5 Jan 2016

Status: Resolved
Project: Swift
Component/s: Compiler

Type: Bug Priority: Medium
Reporter: Nicolas Ameghino Assignee: Unassigned
Resolution: Done Votes: 1
Labels: None
Environment:

Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81)
Target: x86_64-apple-darwin15.2.0


Attachments: Zip Archive StaticNonStaticPlayground.playground.zip    

 Description   

Define a protocol that contains a static function on it. Then write a protocol extension for said protocol that implements a function of the same name but without the static modifier.
When marking a class or struct as conforming to the protocol, the compiler will crash without letting the developer know the cause of the problem.
I ran into this issue by forgetting to add the modifier to the protocol extension. Moreover, the compiler wouldn't tell me that my conforming class wasn't implementing the specified method.

See the attached playground for an example.
If the function in the protocol extension has a different name, the compiler will catch it and let the developer know that the conforming class is missing said function.

Here is the stack trace that Xcode outputs:

0  swift                    0x000000010e5c0fbb llvm::sys::PrintStackTrace(__sFILE*) + 43
1  swift                    0x000000010e5c16fb SignalHandler(int) + 379
2  libsystem_platform.dylib 0x00007fff89510eaa _sigtramp + 26
3  libsystem_platform.dylib 0x00007fff535566a8 _sigtramp + 3389282328
4  swift                    0x000000010c887707 swift::SILWitnessVisitor<(anonymous namespace)::SILGenConformance>::visitProtocolDecl(swift::ProtocolDecl*) + 999
5  swift                    0x000000010c884ee5 swift::Lowering::SILGenModule::getWitnessTable(swift::ProtocolConformance*) + 277
6  swift                    0x000000010c8d45b0 (anonymous namespace)::SILGenType::emitType() + 1264
7  swift                    0x000000010c8d404e swift::Lowering::SILGenModule::visitNominalTypeDecl(swift::NominalTypeDecl*) + 30
8  swift                    0x000000010c85cbdb swift::Lowering::SILGenModule::emitSourceFile(swift::SourceFile*, unsigned int) + 779
9  swift                    0x000000010c85d790 swift::SILModule::constructSIL(swift::ModuleDecl*, swift::SILOptions&, swift::FileUnit*, llvm::Optional<unsigned int>, bool, bool) + 928
10 swift                    0x000000010c85db3d swift::performSILGeneration(swift::FileUnit&, swift::SILOptions&, llvm::Optional<unsigned int>, bool) + 109
11 swift                    0x000000010c6b1992 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&) + 11442
12 swift                    0x000000010c6aead3 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 2691
13 swift                    0x000000010c6ab154 main + 2324
14 libdyld.dylib            0x00007fff8c4e65ad start + 1
15 libdyld.dylib            0x0000000000000049 start + 1941019293


 Comments   
Comment by Greg Titus [ 23 Dec 2015 ]

Current trunk handles this gracefully:

static.swift:13:1: error: type 'TestClass' does not conform to protocol 'TestProtocol'
extension TestClass : TestProtocol { }
^
static.swift:2:17: note: protocol requires function 'foo()' with type '() -> ()'
    static func foo()
                ^
static.swift:6:10: note: candidate operates on an instance, not a type as required
    func foo() {
Comment by Nicolas Ameghino [ 28 Dec 2015 ]

Should I close this ticket?

Comment by Sophie Parker [ 31 Dec 2015 ]

I have had this same bug triggered by implementing a protocol with

class func x() -> Self

without protocol extensions.

Comment by Jordan Rose [ 4 Jan 2016 ]

Sophie, were you using Xcode's Swift, or one of the snapshots from GitHub? If the former, I think we can call this fixed and close it.

Comment by Sophie Parker [ 4 Jan 2016 ]

Ah yes that was in Xcode Swift (2.1.1). I've been away so I was unable to download the snapshot and check it there, but given it's the same bug, I agree it should be closed.

Comment by Jordan Rose [ 5 Jan 2016 ]

Okay, I've marked it as "resolved". Nicolas, you can close it now, or when you get a chance to test that it's fixed (which could be an Xcode beta).

Comment by Nicolas Ameghino [ 5 Jan 2016 ]

I'll close it down, test it in next Xcode beta and reopen if needs be, does that sound good?

Comment by Jordan Rose [ 5 Jan 2016 ]

Yep, that's fine. Thanks!

Generated at Thu Feb 22 14:35:51 CST 2018 using JIRA 7.3.4#73015-sha1:a262b3457b3605f12635df4b0a0c3dc71d631a1e.