GSB: The combination of a superclass and conformance requirement might force a type to be concrete

[slavapestov]

Let's use the redundant requirement graph to diagnose these, just like we already do for redundant conformance and layout requirements.

Also, diagnose conflicts:

• Multiple superclass requirements where neither is a superclass of the other
• A superclass requirement and a concrete type requirement that is not a subclass
• A layout requirement and a concrete type requirement that does not satisfy the layout requirement

The first two were already being diagnosed, the third is new. Here is an example:

struct G<T : AnyObject> {}

extension G where T == Int {}

We now reject this on account of T not satisfying AnyObject.

And last but not least, another bug fix. A protocol can constrain an associated type to Self:

protocol P {
  associatedtype A : Q where A.B == Self
}

protocol Q {
  associatedtype B
}

And a class might conform to this protocol:

class C : P {
  typealias A = D
}

class D : Q {
  typealias B = C
}

The generic signature <Self where Self : P, Self : C> is built during conformance checking. Since Self : C, we must have that Self.A == D; since D.B == C, the requirement A.B == Self in protocol P implies that Self == C. So the correct minimized signature here is <Self where Self == C>.

This wasn't handled properly before, because of assumptions in removeSelfDerived() and a couple of other places.

Fixes rdar://71677712, rdar://76155506, https://bugs.swift.org/browse/SR-10033, https://bugs.swift.org/browse/SR-13884.

[slavapestov]

@swift-ci Please smoke test

[slavapestov]

@swift-ci Please test source compatibility

[slavapestov]

swiftlang/sourcekit-lsp#384
@swift-ci Please smoke test macOS