Comment by Svyatoslav Scherbina (JIRA)

The similar test crashes with segmentation fault if Foo is protocol.

The issue seem to appear only when the corresponding Objective-C class or protocol definition is not found among linked binaries.

I think it's reasonable for that not to work, but it would be nice™ if it gave a more direct error message. cc @DougGregor

I agree with both of Jordan's comments: it's reasonable for this to fail, because the metadata for `Foo` needs to exist in the binary. It would also be wonderful to have a more specific error message when the process of constructing types from a mangled name fails.

Comment by Svyatoslav Scherbina (JIRA)

Please consider the following two failing examples:

1.

import Accounts

class Base<T> {}
class Derived : Base<ACAccount> {}

Derived()

Accounts framework is not linked because not considered as used by the compiler. And then Swift runtime fails because it can't find the class from this framework.

2.

import Foundation

class Base<T> {}
class Derived : Base<NSURLDownloadDelegate> {}

Derived()

Foundation framework is linked, but protocols code is generated on demand, and NSURLDownloadDelegate hasn't been requested properly. So it can't be found at runtime and the application crashes with segmentation fault.

Do you still find current behaviour completely reasonable?

Both of those cases are bugs in the compiler (or linker) in that they don't consider the framework to be used! Can you file a separate bug for that?

Comment by Svyatoslav Scherbina (JIRA)

Sure! SR-10217