[swift-dev] SubstitutionMap questions

Jacob Bandes-Storch jtbandes at gmail.com
Fri Dec 30 14:14:52 CST 2016

Happy holidays :-)

I started looking at this bug to see if I could figure out how to fix it:

As the bug author points out, there is a TODO in
GenericSignature::getSubstitutionMap, saying it needs to handle same-type

Most of the stuff going on here is way over my head right now, but maybe I
can get there by asking some questions. Here is my repro case:

    protocol P { associatedtype Pmember }

    struct Bar {}
    struct Foo: P { typealias Pmember = Bar }

    protocol A {
      associatedtype Amember: P
      func doSomething() -> Amember.Pmember

    extension A where Amember == Foo {
      func extensionFunc() {
        doSomething()  // crash occurs when trying to subst() this call's
return type

Ultimately the problem is that, during
SILFunctionType::substGenericArgs, getMemberForBaseType() returns null when
called on the DependentMemberType (the function result type), because the
result of lookupConformances is not concrete:

Here are some things I don't understand:

1. Why does LookupConformanceFn return only a single conformance? Couldn't
there be more than one conformance for a particular generic param?

2. Why does finding an abstract conformance constitute a failure
of getMemberForBaseType?

3. At the lookupConformances call
origBase is "τ_0_0.Amember", and substBase is the concrete type "Foo".
However, the LookUpConformanceInSubstitutionMap drops the substBase (
*conformingReplacementType)* on the floor

4. Finally, is SubstitutionMap really the right place for same-type
requirements? Maybe getMemberForBaseType would need more context passed to
it than just the LookupConformanceFn?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20161230/1b3fe7f7/attachment.html>

More information about the swift-dev mailing list