Comment by Erik Little (JIRA)

Also seeing a similar error with this example.

// Having Phase above causes an error in GameRules

#if PHASE_ABOVE
public protocol Phase {
  associatedtype RulesType: GameRules where RulesType.PhaseType == Self
}
#endif

public protocol GameRules {
  associatedtype ContextType: GameContext where ContextType.RulesType == Self
  associatedtype PhaseType: Phase where PhaseType.RulesType == Self
  associatedtype PlayerType: Player where PlayerType.RulesType == Self

  // Error here when `Phase` is above this protocol. Error: Instance method requirement cannot add constraint ... on Self
  mutating func executeTurn(forPlayer player: PlayerType)
}

// But having it below is fine
#if !PHASE_ABOVE
public protocol Phase {
  associatedtype RulesType: GameRules where RulesType.PhaseType == Self
}
#endif

public protocol GameContext : AnyObject {
  associatedtype RulesType: GameRules where RulesType.ContextType == Self
}

public protocol Player : AnyObject, Hashable {
  associatedtype RulesType: GameRules where RulesType.PlayerType == Self
}

@huonw?

The error seems weird, but as you say, it seems like that's gone away with the development snapshot, for the first example. (FWIW, based on my analysis below, it seems like you actually don't need both B and C for the first case: the only way to conform to that protocol ends up with them being equal.)

@DougGregor: The requirement signature ends up being <Self where Self == Self.B.A, Self.B : P, Self.B == Self.C>, and so the requirements on Self.C are "redundant", but of course they're necessary to deduce that Self.B == Self.C and deleting it results in legitimate errors (the logic is, something like: Self == Self.C.A from Self: Q, Self.C.A.B == Self.C from Self.C: P together imply Self.B == Self.C after rewriting the prefix of the first type of the second requirement using the first requirement).

I still see errors with the second example, but only when all of the associated types exist: deleting, say, GameContext and ContextType stops the error occurring. It looks like it's the GSB adding too many same-type requirements and not eliminating them all, so it still exists in the generic signature of that method.

@swift-ci create

Here's what I get for my second example with dev snapshot 2018-06-08:

protocol P {
    associatedtype A: Q where A.B == Self
}
protocol Q {
    associatedtype B: P where B.A == Self
    associatedtype C: P where C.A == Self // Warning: Redundant conformance constraint 'Self.C': 'P'
}

So the error is gone, but the warning is a bug since that conformance is clearly not redundant.

@huonw: "The error seems weird, but as you say, it seems like that's gone away with the development snapshot, for the first example. (FWIW, based on my analysis below, it seems like you actually don't need both B and C for the first case: the only way to conform to that protocol ends up with them being equal.)"

Note that the first example has never been meant to demonstrate a bug (it's clearly stated in the report), it was just meant to illustrate why the second should work, just like the first.

The following variant crashes the default toolchain of Xcode 10 beta, and dev snapshot 2018-06-08 produces the compile time errors below.

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

struct X<T: Q> : P {
    typealias A = Y<X>
}

struct Y<T: P> : Q {
    typealias B = X<Y>
}

Error for X: 'P' requires the types 'X<T>' and 'X<Y<X<T>>>' be equivalent
Error for Y: 'Q' requires the types 'Y<T>' and 'Y<X<Y<T>>>' be equivalent

The following compiles though:

struct X<T> {
    typealias A = Y<X>
}

struct Y<T> {
    typealias B = X<Y>
}

#42113