This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
This optimizes for the case where we have a disjunction that contains an
operator defined in a protocol, and a protocol defined in a protocol
extension, and furthermore, the protocol extension operator's type is a
refinement of the protocol requirement operator's type.
In this case, there are three possibilities:
- Either the operator requirement is witnessed by a concrete operator
in the conforming type, in which case the solution involving the
protocol extension operator is going to be worse, so we can skip this
choice.
- Otherwise, the protocol requirement operator is witnessed by the same
protocol extension operator that we skipped, in which case we will find
the same solution if we just pick the protocol requirement operator
anyway.
- The only other possibility is that the protocol requirement operator
is witnessed by a protocol extension operator, but also, a more
refined protocol extension operator exists. However, it appears that in
this case, solution ranking _also_ picks the solution involving the
protocol requirement operator, as the new test case demonstrates.
Thus, we gain nothing by considering these protocol extension operators.
Skip them when forming the disjunction.
This is a reduction of the problem from rdar://168618780 which is
independent of the workaround https://github.com/swiftlang/swift/pull/86745.
Once this is fixed, the workaround PR can be reverted.
If the base captured type still has type variables when we bind the
member function type, form a Sendable dependent function type with
the base type. This will then be eliminated by TypeSimplifier once
all the type variables in the base type have been resolved.
This then allows us to remove the delaying logic from member lookup.
Computing dominance relation between instructions in the same block was done with linear search, e.g. when checking if a value-use is before its lifetime ending instruction.
This resulted in quadratic complexity and very long compile times for very large basic blocks.
Now we do the dominance check with pre-computed instruction indices, which is O(0) instead of O(n).
https://github.com/swiftlang/swift/issues/86663
rdar://168511262
There was an existing CSOptimizer heuristic which improved performance
in the case where && was overloaded, which we weren't testing in our
test suite.
not1 is only fast on accident -- no disjunction scores are assigned,
because we do not consider result type matching when scoring
non-operator disjunctions. We should fix this!
not2 is fast because we do consider parameter types, so we score
disjunctions and solve the innermost one first.
If we have `(_: $T0)`, avoid flattening to `$T0` since for a pack
expansion type variable that would result in a bare pack type instead
of a tuple. Instead, leave the flattening for TypeSimplifier.
