[CSGen] Emulate separate type-checking of $generator variable of for-in loop

Emulate previous `for-in` type-checking behavior where sequence
was type-checked separately from `.next()` call which, in turn,
was injected only during SIL generation.

Current approach to generate an implicit variable for `$generator`
and use it as a base to `.next()` call didn't account for the fact
that it allows the solver to rank result of `<sequence>.makeIterator()`
together with result of `next()`. This is logically incorrect because
`<sequence>.makeIterator()` represents initializer of `$generator`
which is separate from `$generator.next()` expression albeit type-checked
together.

Resolves: #59522
(cherry picked from commit 20a342b)

Author: xedin

lib/Sema/CSGen.cpp

@@ -3950,8 +3950,20 @@ generateForEachStmtConstraints(
     forEachStmtInfo.makeIteratorVar = PB;
 
     // Type of sequence expression has to conform to Sequence protocol.
+    //
+    // Note that the following emulates having `$generator` separately
+    // type-checked by introducing a `TVO_PrefersSubtypeBinding` type
+    // variable that would make sure that result of `.makeIterator` would
+    // get ranked standalone.
     {
-      cs.addConstraint(ConstraintKind::ConformsTo, cs.getType(sequenceExpr),
+      auto *externalIteratorType = cs.createTypeVariable(
+          cs.getConstraintLocator(sequenceExpr), TVO_PrefersSubtypeBinding);
+
+      cs.addConstraint(ConstraintKind::Equal, externalIteratorType,
+                       cs.getType(sequenceExpr),
+                       externalIteratorType->getImpl().getLocator());
+
+      cs.addConstraint(ConstraintKind::ConformsTo, externalIteratorType,
                        sequenceProto->getDeclaredInterfaceType(),
                        contextualLocator);
 

test/stmt/foreach.swift

@@ -245,3 +245,8 @@ func testForEachWhereWithClosure(_ x: [Int]) {
   for i in x where x.contains(where: { $0.byteSwapped == i }) {}
 }
 
+// https://github.com/apple/swift/issues/59522 - use of `prefix` with generic base causes ambiguity in for-in statement
+func test_no_ambiguity_with_prefix_iterator<C: Collection>(c: C) {
+  for _ in c.prefix(1) { // Ok
+  }
+}