[WIP] [4.2] Allow a specialized conformance to fail

[jrose-apple]

This handles the case where a conditional conformance cannot be inherited because the subclass provides a generic argument that doesn't satisfy the conditional requirements.

SR-7337 / rdar://problem/39142121

[jrose-apple]

Does this even make sense? It does make the crash from SR-7337 go away, but I have no idea what else it might break. I also don't know what the equivalent change would be on master. The original test case no longer fails because we don't serialize substitutions, but that doesn't mean that everything is working as intended.

@swift-ci Please test

[jrose-apple]

@swift-ci Please test source compatibility

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 872ceea

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 872ceea

[jrose-apple]

Well, this crashed building the stdlib, so maybe not.

[slavapestov]

@jrose-apple We crash on 4.2 but not on master because of differences in how SubstitutionMap and SubstitutionList were represented.

Suppose we have this generic signature:

<T : P where T.X : Q>

protocol P { associatedtype X }
protocol Q {}

Now let's say we have an invalid substitution T := Foo, where Foo is some struct that doesn't conform to P (or maybe it conforms to P, but it's X doesn't conform to Q). Then the substitution map will record the replacement type Foo and a conformance for T : P. Since it doesn't conform, it ends up recording an abstract conformance (this is bad for other reasons, but we can serialize an abstract conformance).

On the other hand, a substitution list will store the replacement type for T, and the replacement type for T.X. Since T doesn't have an X, the second replacement type is an ErrorType, which cannot be serialized.

It's funny because I was going to add an 'invalid' bit to SubstitutionMap to represent maps where some conformances are missing, because this will allow us to enforce stronger invariants (concrete type must have concrete conformance, and vice versa, instead of treating an abstract conformance as an 'error conformance'). However if we do that, presumably we don't want to serialize invalid SubstitutionMaps, and we'd end up with the same crash on master.

So I don't really know what the right fix here is. Perhaps inherited conformances should not serialize their substitutions; I think they can always be re-constructed at runtime. You mentioned not serializing inherited conformances at all, but I don't know what that means; they can be referenced from other entities that get serialized, so you have to serialize something.

[jrose-apple]

Your explanation makes sense but doesn't exactly give us a way forward. :-) It would be nice™ to not crash here in 4.2. What about something much smaller, like putting a null type in the serialized Substitution? Or allowing error types just in this one location? I mean, it should never be used, right?

[jrose-apple]

Closing in favor of #17523.