RequirementMachine: Unwrap outer TypeAliasType on protocol typealiases

A protocol typealias 'typealias T = X' introduces a same-type requirement
'Self.T == Self.X'. However the right hand side of the requirement was
wrapped in a sugared TypeAliasType.

This meant if the requirement surfaced in a redundancy diagnostic, it
would print as 'Self.T == Self.T'. It could also trigger a request cycle
via isInterestingTypealias() in DiagnosticEngine.cpp.

Author: slavapestov

lib/AST/RequirementMachine/RequirementLowering.cpp

@@ -712,7 +712,13 @@ StructuralRequirementsRequest::evaluate(Evaluator &evaluator,
         if (assocTypes.contains(typeAliasDecl->getName()))
           continue;
 
+        // The structural type of a typealias will always be a TypeAliasType,
+        // so unwrap it to avoid a requirement that prints as 'Self.T == Self.T'
+        // in diagnostics.
         auto underlyingType = typeAliasDecl->getStructuralType();
+        if (auto *aliasType = dyn_cast<TypeAliasType>(underlyingType.getPointer()))
+          underlyingType = aliasType->getSinglyDesugaredType();
+
         if (underlyingType->is<UnboundGenericType>())
           continue;
 

test/Generics/protocol_typealias_cycle_5.swift

@@ -0,0 +1,7 @@
+// RUN: %target-typecheck-verify-swift -requirement-machine-protocol-signatures=on
+
+protocol P : Sequence {
+  typealias Element = Iterator.Element
+  // expected-warning@-1 {{typealias overriding associated type 'Element' from protocol 'Sequence' is better expressed as same-type constraint on the protocol}}
+  // expected-warning@-2 {{redundant same-type constraint 'Self.Element' == 'Self.Iterator.Element'}}
+}