IRGen: Terrible workaround for problem in searchNominalTypeMetadata()

This fixes a regression introduced by e3c8f42,
but the root cause was actually a subtle invariant violation
in IRGen.

FulfillmentMap's use of canonical types as keys assumes that
canonical type equality is sufficient for checking if two types
"are the same". However, this is not true when those types
contain type parameters, because two distinct type parameters
might belong to the same equivalence class.

Thus, when we take the type's context substitution map, and
apply it to each type parameter in our given list of
requirements, the substitution operation could output a
different but equivalent type parameter.

As a workaround for this problem, try to preserve the old
behavior of subst() in this specific case.

Fixes rdar://160649141.

Author: slavapestov

lib/IRGen/Fulfillment.cpp

@@ -380,7 +380,24 @@ bool FulfillmentMap::searchNominalTypeMetadata(IRGenModule &IGM,
 
   for (unsigned reqtIndex : indices(requirements.getRequirements())) {
     auto requirement = requirements.getRequirements()[reqtIndex];
-    auto arg = requirement.getTypeParameter().subst(subs)->getCanonicalType();
+
+    // FIXME: The correct fix is to pass down the substitution map's
+    // output generic signature and reduce the result of subst() with
+    // this signature before forming the lookup key.
+    //
+    // Once that's fixed, change the below back to this:
+    // auto arg = requirement.getTypeParameter().subst(subs)->getCanonicalType();
+
+    auto arg = requirement.getTypeParameter().subst(
+      QuerySubstitutionMap{subs},
+      [&](InFlightSubstitution &IFS, Type origType, ProtocolDecl *proto)
+            -> ProtocolConformanceRef {
+        auto substType = origType.subst(IFS);
+        if (substType->isTypeParameter())
+          return ProtocolConformanceRef::forAbstract(substType, proto);
+
+        return subs.lookupConformance(origType->getCanonicalType(), proto);
+      })->getCanonicalType();
 
     // Skip uninteresting type arguments.
     if (!keys.hasInterestingType(arg))

test/IRGen/fulfillment_map_key_equality.swift

@@ -0,0 +1,44 @@
+// RUN: %target-swift-frontend -emit-ir %s -enable-library-evolution | %FileCheck %s
+
+// FIXME: We just need to adjust the check line below, there's no inherent
+// reason for this not to be tested on wasm.
+// UNSUPPORTED: CPU=wasm32
+
+// rdar://160649141
+
+public protocol P1 {}
+
+public protocol P2 {
+  associatedtype A1
+}
+
+public protocol P5 {
+  associatedtype A2: P2
+}
+
+public protocol P3 where A4.A1 == A3.A2.A1 {
+  associatedtype A3: P5
+  associatedtype A4: P2
+
+  var x: Int { get }
+}
+
+public protocol P6: P3 {}
+
+public protocol P4 {
+  associatedtype A4: P2
+}
+
+public struct G1<A1>: P2 {}
+
+public struct G2<A2: P2>: P5  {}
+
+public struct G3<T: P6 & P4>: P3 where T.A4.A1: P1 {
+  public typealias A4 = G1<T.A3.A2.A1>
+  public typealias A3 = G2<T.A3.A2>
+
+  // Make sure this witness thunk doesn't have any additional bogus parameters.
+
+  // CHECK-LABEL: define internal swiftcc i64 @"$s28fulfillment_map_key_equality2G3VyxGAA2P3A2aEP1xSivgTW"(ptr noalias swiftself captures(none) %0, ptr %Self, ptr %SelfWitnessTable) {{.*}} {
+  public var x: Int { fatalError() }
+}