AssociatedTypeInference: Initial refactoring of abstract type witness inference

[AnthonyLatsis]

No description provided.

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please clean smoke test macOS

[slavapestov]

Does this PR fix the problem where associated types must be re-stated in inherited protocols?

Eg, this doesn't type check today:

protocol Base {
  associatedtype A
}

protocol Derived : Base {
  func foo() -> A
}

struct S : Derived {
  func foo() -> Int { return 0 }
}

You need to pointlessly re-declare the 'associatedtype A' inside 'protocol Derived'. It would be nice to make this work.

[slavapestov]

What about Self.X.Y == Self.X.Y.*, etc?

[AnthonyLatsis]

Anything other than Self.X := Y is not considered at all.

[slavapestov]

It looks like this is sensitive to the order of protocols in the inheritance clause, which might be weird. Perhaps you should canonicalize the list of inherited protocols when walking (or walk over conformance requirements on 'Self' in the requirement signature instead, which are in canonical order).

[slavapestov]

@AnthonyLatsis can you run source compat testing on this once you resolve the merge conflict?

[AnthonyLatsis]

Does this PR fix the problem where associated types must be re-stated in inherited protocols?

Not in general, I haven't touched inference via value witnesses yet.

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@slavapestov source compatibility failures are unrelated, but in isolation this is in fact a source breaking change. There is a group of conformances we are not yet prepared to deal with for which associated type inference now fails. A selected few of these compile today, e.g.

protocol P { associatedtype A = Int }
protocol Q { associatedtype B }
protocol R: P, Q where A == B {}

struct S: R {} // A := Int, B := Int (correct)

and while some infer the correct type witnesses by chance like the above, others do not:

protocol P { associatedtype B = Int }
protocol Q { associatedtype A }
protocol R: P, Q where A == B {}

struct S<A>: R {} // A := A (generic parameter), B := A (wrong)

They all have two things in common: you need more information than just the same-type constraints to decide on a type witness, and the type witnesses of one conformance cannot be resolved independently of another in general.
I reckon that having something fail before it starts working properly is better than a sudden change in behavior. Still, I would like to hear your thoughts on whether we should gate this behind a flag until the global issue is addressed.

[AnthonyLatsis]

@swift-ci please test source compatibility

Let's make these green.

[AnthonyLatsis]

The probability of someone relying on the entailing source compatibility nuance I mentioned is really low, given that these cases just started "working" in the last minor release or so, so I'm going to merge this and try do deal with the existing bigger issue in 5.7. Then again, we can always defer or revert this if something goes left.

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@swift-ci clean smoke test macOS

[AnthonyLatsis]

@swift-ci clean smoke test macOS

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@shahmishal Did something happen with the archiving of build artefacts in source compat builds?

[AnthonyLatsis]

@swift-ci please test source compatibility