[SR-7353] Invalid error and warning related to recursive constraints on associated type

[jepers]

Previous ID	SR-7353
Radar	rdar://problem/39225307
Original Reporter	@jepers
Type	Bug
Status	Resolved
Resolution	Done

Environment

Xcode 9.3, default toolchain and eg dev snapshot 2018-03-28

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: c26cdc0dbaf628a2e81a170395fe5d27

Issue Description:

Note that the following compiles as expected (in Xcode 9.3):

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

But adding a second associated type `C` to `Q` will produce the following invalid error and warning:

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 // Error and Warning
}
// Error: `A` is not a member of type `Self.C`
// Warning: Redundant conformance constraint 'Self.C': 'P'

BUT: The error goes away (but not the warning) if the protocol definitions are swapped, so that Q is defined before P. Also, there is no error when using eg dev snapshot 2018-03-28, no matter the order of P and Q.

[swift-ci]

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
}

[belkadan]

@huonw?

[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.

[huonw]

@swift-ci create

[jepers]

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.

[jepers]

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>
}

[slavapestov]

#42113