RequirementMachine: Workaround invariant violation when requirement signature completion fails

- If P is declared to inherit from Q and Q has an associated type named U, then
  isValidTypeInContext() returns true for a type 'T.U' where 'T' is a generic
  parameter conforming to P, and 'U' is the unresolved DependentMemberType, and
  the type 'T.U' will simplify to the term 'T.[P:U]'.

- However, if completion failed while building the rewrite system for P's
  requirement signature, then the requirement signature for P won't have a
  rule [P].[Q] => [P]. As a result, getTypeForTerm() will fail when given
  'T.[P:U]', because the property map entry for 'T' will not contain a
  conformance to Q.

Work around this by manually adding protocol inheritance rules when building
a signature from a protocol whose requirement signature failed to compute.

This was triggered by the test case I added in the previous commit to
test/Generics/non_confluent.swift.

Author: slavapestov

lib/AST/RequirementMachine/RuleBuilder.cpp

@@ -101,6 +101,21 @@ void RuleBuilder::initWithProtocolSignatureRequirements(
     addPermanentProtocolRules(proto);
 
     auto reqs = proto->getRequirementSignature();
+
+    // If completion failed, we'll have a totally empty requirement signature,
+    // but to maintain invariants around what constitutes a valid rewrite term
+    // between getTypeForTerm() and isValidTypeInContext(), we need to add rules
+    // for inherited protocols.
+    if (reqs.getErrors().contains(GenericSignatureErrorFlags::CompletionFailed)) {
+      for (auto *inheritedProto : Context.getInheritedProtocols(proto)) {
+        Requirement req(RequirementKind::Conformance,
+                        proto->getSelfInterfaceType(),
+                        inheritedProto->getDeclaredInterfaceType());
+
+        addRequirement(req.getCanonical(), proto);
+      }
+    }
+
     for (auto req : reqs.getRequirements())
       addRequirement(req.getCanonical(), proto);
     for (auto alias : reqs.getTypeAliases())