Comment by Svyatoslav Scherbina (JIRA)

(First reported in SR-10177).

Thank you!

Comment by Eric Yanush (JIRA)

This issue has caused an entire set of projects to crash at runtime when built with Xcode 10.2. This bug will prevent my organization from upgrading from Xcode 10.1 to 10.2 (& Swift 5.0).

In our case, we have a pure Swift dynamic framework that encapsulates all of our common base classes and other common functionality. Currently we know that at least one of the generic classes in our common framework, which inherits from a class in an external framework (GroupProcedure from ProcedureKit), is causing runtime crashes when a concrete subclass is defined outside of the common framework.

I've also noticed that the mangled name reported in the runtime crash, is not demangle-able by swift-demangle. I've included the mangled name reported (with proprietary names replaced with placeholders).

8CommonFramework10FetchGroupCyAA32DownloadSecuredResourceProcedureC5ProductFramework9APITicketVytAE0G10KitNetwork0K9OperationA2A0ekG0C0gJ006OutputG0HPyHC_AI19HTTPPayloadResponseVy10Foundation4DataVGAI0nO8ProtocolHPyHCHCg1_G

The workaround is to use the type somewhere in your program that's not a generic argument, even if you don't do anything with it. For the class case, you should be able to explicitly link the framework without any source changes as well, rather than relying on autolinking.

Replacing proprietary names by placeholders might mess up the mangled name, unfortunately, so we can't do anything with that. Can you share the original name with just Apple at https://bugreport.apple.com?

Comment by Eric Yanush (JIRA)

@belkadan Done! Submitted as problem 49391672, with code attached.

Reverted @bob-wilson's Radar change since that's a separate issue.

(Eric, I'm treating your Radar as being about the mangling; we can keep using this JIRA to track the "the compiler should link the framework" issue.)

OK, sorry, I misunderstood. What about SR-10177? Is that also a separate issue?

Yep, that's about the diagnostic in the runtime. If we ever come up with a way to turn off autolinking (or if we have other bugs) that'll still be relevant.

Comment by Eric Yanush (JIRA)

An update to my issue:

I was able to identify a workaround, which is to specify the superclass type as the type parameter used in my sub-type declaration. For example:

class GenericOne<T> { }
class Other { }
class DerivedOne: GenericOne<Other> { }

class GenericTwo<T, U , V> { }

// This will cause a runtime error stating that the super class of ProblemClass cannot be demangled.
class ProblemClass: GenericTwo<DerivedOne, Int, String> { }

// This works
class ProblemClass: GenericTwo<GenericOne<Other>, Int, String> { }

This is starting to sound like a completely different issue from what Svyatoslav is describing. Is that what's in your Radar?

Comment by Eric Yanush (JIRA)

Yes it is.