Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-1939] Swift 3 crashes conforming class to protocol with generic type constraints #44548

Closed
swift-ci opened this issue Jun 30, 2016 · 10 comments
Closed

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Jun 30, 2016

Previous ID SR-1939
Radar rdar://problem/27777714
Original Reporter banjun (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate
Environment

Xcode 8 beta 1

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 3.0Regression, CompilerCrash
Assignee None
Priority Medium

md5: bf2ba52b099580173be1106d51322ac7

relates to:

  • SR-2101 Generics compiler crash regression

Issue Description:

This example case cause crash of Swift 3 compiler.

protocol P1 {
    associatedtype A1: Equatable
}

class C1<T, U: P1 where U.A1 == T>: P1 {
    typealias A1 = T
}
% /Users/banjun/Downloads/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift ~/Downloads/swift3crash-2.swift
0  swift                    0x0000000108f0d34b llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 43
1  swift                    0x0000000108f0c636 llvm::sys::RunSignalHandlers() + 70
2  swift                    0x0000000108f0d99f SignalHandler(int) + 287
3  libsystem_platform.dylib 0x00007fff8cc6f52a _sigtramp + 26
4  libsystem_platform.dylib 0x00007fff59268df0 _sigtramp + 3428817120
5  swift                    0x00000001069e8dab swift::irgen::emitAssociatedTypeWitnessTableRef(swift::irgen::IRGenFunction&, swift::CanTypeWrapper<swift::ArchetypeType>, swift::AssociatedTypeDecl*, llvm::Value*, swift::ProtocolDecl*) + 43
6  swift                    0x00000001069ea9a9 llvm::Value* llvm::function_ref<llvm::Value* (unsigned int)>::callback_fn<swift::irgen::emitArchetypeWitnessTableRef(swift::irgen::IRGenFunction&, swift::CanTypeWrapper<swift::ArchetypeType>, swift::ProtocolDecl*)::$_0>(long, unsigned int) + 361
7  swift                    0x0000000106a78450 swift::irgen::emitImpliedWitnessTableRef(swift::irgen::IRGenFunction&, llvm::ArrayRef<swift::irgen::ProtocolEntry>, swift::ProtocolDecl*, llvm::function_ref<llvm::Value* (unsigned int)> const&) + 240
8  swift                    0x00000001069e8d72 swift::irgen::emitArchetypeWitnessTableRef(swift::irgen::IRGenFunction&, swift::CanTypeWrapper<swift::ArchetypeType>, swift::ProtocolDecl*) + 130
9  swift                    0x0000000106a7b4df swift::SILWitnessVisitor<(anonymous namespace)::WitnessTableBuilder>::visitProtocolDecl(swift::ProtocolDecl*) + 4847
10 swift                    0x0000000106a7613e swift::irgen::IRGenModule::emitSILWitnessTable(swift::SILWitnessTable*) + 414
11 swift                    0x0000000106a138ad swift::irgen::IRGenerator::emitGlobalTopLevel() + 909
12 swift                    0x0000000106aa097b performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, unsigned int) + 1131
13 swift                    0x0000000106a9f83d swift::performIRGeneration(swift::IRGenOptions&, swift::ModuleDecl*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&) + 621
14 swift                    0x00000001069dcc4a swift::RunImmediately(swift::CompilerInstance&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, swift::IRGenOptions&, swift::SILOptions const&) + 154
15 swift                    0x00000001069ce2e4 performCompile(swift::CompilerInstance&, swift::CompilerInvocation&, llvm::ArrayRef<char const*>, int&, swift::FrontendObserver*) + 15732
16 swift                    0x00000001069c9619 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) + 2873
17 swift                    0x00000001069976c4 main + 2852
18 libdyld.dylib            0x00007fff8e9955ad start + 1
19 libdyld.dylib            0x000000000000000c start + 1902553696
Stack dump:
0.  Program arguments: /Users/banjun/Downloads/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift -frontend -interpret /Users/banjun/Downloads/swift3crash-2.swift -target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Users/banjun/Downloads/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -color-diagnostics -module-name main 
zsh: segmentation fault   ~/Downloads/swift3crash-2.swift

and locally built toolchain (on commit of #3093 ) prints error message before backtrace below:

no relation found that declares conformance to target
UNREACHABLE executed at /Users/banjun/projects/swift-source/swift/lib/IRGen/GenArchetype.cpp:140!

For reproducing the issue, it is not required that `C1` and `U` have same protocol comformance to `P1`.
i.e. using another protocol `P2` reproduce the same error message and crash.

protocol P1 {
    associatedtype A1: Equatable
}

protocol P2 {
    associatedtype A2: Equatable
}

class C1<T, U: P1 where U.A1 == T>: P2 {
    typealias A2 = T
}

This issue might be related to SR-1426, but I'm not sure this duplicates.
This issue does not reproduce with swift of Xcode 7.3.1.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Jun 30, 2016

The usual way to write this type is just

class C1<U: P1>: P2 {
  typealias A2 = U.A1
}

but we still shouldn't crash.

@ahoppen
Copy link
Collaborator

@ahoppen ahoppen commented Jul 13, 2016

This compiles fine on current master. Seems to have been fixed

@CodaFi
Copy link
Member

@CodaFi CodaFi commented Jul 13, 2016

I can still reproduce this.

@ahoppen
Copy link
Collaborator

@ahoppen ahoppen commented Jul 13, 2016

@CodaFi (JIRA User): OK, that's interesting. I just double checked and both the first and the second example build just fine for me on master commit cf93e65 on macOS. Which commit on which platform are you using?

@CodaFi
Copy link
Member

@CodaFi CodaFi commented Jul 13, 2016

I've just rebased onto 061b681 and can still see both crashes. You must run these tests with the interpreter.

@ahoppen
Copy link
Collaborator

@ahoppen ahoppen commented Jul 14, 2016

Oh, sorry my bad, I just ran swift -frontend -parse.

@ddunbar
Copy link
Member

@ddunbar ddunbar commented Jul 26, 2016

Maybe just a dup of:
https://bugs.swift.org/browse/SR-1426

@belkadan
Copy link
Contributor

@belkadan belkadan commented Jul 26, 2016

For future reference, -parse stops after type-checking.

@bob-wilson
Copy link

@bob-wilson bob-wilson commented Sep 22, 2016

I'm pretty sure this is a duplicate of one of the crashes reported in SR-1951, which was fixed in #4330 It no longer crashes for me.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Oct 5, 2016

Comment by BAN Jun (JIRA)

I've just confirmed 3.0.0 with Xcode 8.0 still reproduce the issue, and, Swift 3.0.1 Preview 1 (downloaded from swift.org) does not reproduce this issue. It's fixed.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants