Sema: Don't resolve protocol typealiases to DependentMemberTypes

Author: slavapestov

lib/Sema/TypeCheckType.cpp

@@ -406,22 +406,14 @@ Type TypeResolution::resolveTypeInContext(TypeDecl *typeDecl,
 
     if (selfType->is<GenericTypeParamType>()) {
       if (typeDecl->getDeclContext()->getSelfProtocolDecl()) {
-        if (isa<AssociatedTypeDecl>(typeDecl) ||
-            (isa<TypeAliasDecl>(typeDecl) &&
-             !cast<TypeAliasDecl>(typeDecl)->isGeneric())) {
-          // FIXME: We should use this lookup method for the Interface
-          // stage too, but right now that causes problems with
-          // Sequence.SubSequence vs Collection.SubSequence; the former
-          // is more canonical, but if we return that instead of the
-          // latter, we infer the wrong associated type in some cases,
-          // because we use the Sequence.SubSequence default instead of
-          // the Collection.SubSequence default, even when the conforming
-          // type wants to conform to Collection.
-          if (getStage() == TypeResolutionStage::Structural) {
-            return DependentMemberType::get(selfType, typeDecl->getName());
-          } else if (auto assocType = dyn_cast<AssociatedTypeDecl>(typeDecl)) {
-            typeDecl = assocType->getAssociatedTypeAnchor();
-          }
+        auto *aliasDecl = dyn_cast<TypeAliasDecl>(typeDecl);
+        if (getStage() == TypeResolutionStage::Structural &&
+            aliasDecl && !aliasDecl->isGeneric()) {
+          return aliasDecl->getStructuralType();
+        }
+
+        if (auto assocType = dyn_cast<AssociatedTypeDecl>(typeDecl)) {
+          typeDecl = assocType->getAssociatedTypeAnchor();
         }
       }
 
@@ -2438,14 +2430,7 @@ TypeResolver::resolveAttributedType(TypeAttributes &attrs, TypeRepr *repr,
   // context, and then set isNoEscape if @escaping is not present.
   if (!ty) ty = resolveType(repr, instanceOptions);
   if (!ty || ty->hasError()) return ty;
-
-  // Type aliases inside protocols are not yet resolved in the structural
-  // stage of type resolution
-  if (ty->is<DependentMemberType>() &&
-      resolution.getStage() == TypeResolutionStage::Structural) {
-    return ty;
-  }
-
+  
   // Handle @escaping
   if (ty->is<FunctionType>()) {
     if (attrs.has(TAK_escaping)) {

test/decl/protocol/req/associated_type_ambiguity.swift

@@ -1,36 +1,27 @@
 // RUN: %target-typecheck-verify-swift
 
-// Reference to associated type from 'where' clause should not be
+// References to associated type from 'where' clause should be
 // ambiguous when there's a typealias with the same name in another
-// protocol.
-//
-// FIXME: The semantics here are still really iffy. There's also a
-// case to be made that type aliases in protocol extensions should
-// only act as defaults and not as same-type constraints. However,
-// if we decide to go down that route, it's important that *both*
-// the unqualified (T) and qualified (Self.T) lookups behave the
-// same.
+// unrelated protocol.
+
 protocol P1 {
-  typealias T = Int // expected-note {{found this candidate}}
+  typealias T = Int // expected-note 3{{found this candidate}}
 }
 
 protocol P2 {
-  associatedtype T // expected-note {{found this candidate}}
+  associatedtype T // expected-note 3{{found this candidate}}
 }
 
-// FIXME: This extension's generic signature is still minimized differently from
-// the next one. We need to decide if 'T == Int' is a redundant requirement or
-// not.
-extension P1 where Self : P2, T == Int {
-  func takeT1(_: T) {}
-  func takeT2(_: Self.T) {}
+extension P1 where Self : P2, T == Int { // expected-error {{'T' is ambiguous for type lookup in this context}}
+  func takeT11(_: T) {} // expected-error {{'T' is ambiguous for type lookup in this context}}
+  func takeT12(_: Self.T) {}
 }
 
 extension P1 where Self : P2 {
   // FIXME: This doesn't make sense -- either both should
   // succeed, or both should be ambiguous.
-  func takeT1(_: T) {} // expected-error {{'T' is ambiguous for type lookup in this context}}
-  func takeT2(_: Self.T) {}
+  func takeT21(_: T) {} // expected-error {{'T' is ambiguous for type lookup in this context}}
+  func takeT22(_: Self.T) {}
 }
 
 // Same as above, but now we have two visible associated types with the same
@@ -39,20 +30,17 @@ protocol P3 {
   associatedtype T
 }
 
-// FIXME: This extension's generic signature is still minimized differently from
-// the next one. We need to decide if 'T == Int' is a redundant requirement or
-// not.
 extension P2 where Self : P3, T == Int {
-  func takeT1(_: T) {}
-  func takeT2(_: Self.T) {}
+  func takeT31(_: T) {}
+  func takeT32(_: Self.T) {}
 }
 
 extension P2 where Self : P3 {
-  func takeT1(_: T) {}
-  func takeT2(_: Self.T) {}
+  func takeT41(_: T) {}
+  func takeT42(_: Self.T) {}
 }
 
 protocol P4 : P2, P3 {
-  func takeT1(_: T)
-  func takeT2(_: Self.T)
+  func takeT51(_: T)
+  func takeT52(_: Self.T)
 }

test/decl/typealias/protocol.swift

@@ -268,7 +268,7 @@ extension P10 {
   typealias U = Float
 }
 
-extension P10 where T == Int { } // expected-warning{{neither type in same-type constraint ('Self.T' (aka 'Int') or 'Int') refers to a generic parameter or associated type}}
+extension P10 where T == Int { } // expected-warning{{neither type in same-type constraint ('Int' or 'Int') refers to a generic parameter or associated type}}
 
 extension P10 where A == X<T> { }
 
@@ -277,7 +277,7 @@ extension P10 where A == X<U> { }
 extension P10 where A == X<Self.U> { }
 
 extension P10 where V == Int { } // expected-warning {{'V' is deprecated: just use Int, silly}}
-// expected-warning@-1{{neither type in same-type constraint ('Self.V' (aka 'Int') or 'Int') refers to a generic parameter or associated type}}
+// expected-warning@-1{{neither type in same-type constraint ('Int' or 'Int') refers to a generic parameter or associated type}}
 
 // rdar://problem/36003312
 protocol P11 {