Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GSB: Teach 'derived via concrete' computation about superclass constraints #32488

Merged

Conversation

slavapestov
Copy link
Contributor

Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.

For example, consider this code, which we correctly support today:

protocol P {
  associatedtype T : Q
}

protocol Q {}

class SomeClass<U : Q> {}

struct Outer<T> where T : P {
  func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}

The constraint T == SomeClass<U> makes the outer constraint
T : P redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint U == T.T.

However, whereas T : P together with U == T.T make U : Q
redundant, the introduction of the constraint T == SomeClass<U>
removes'T : P, so we re-introduce an explicit constraint U : Q
in order to get a valid generic signature.

This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.

As a result, this case was broken:

struct Outer<T> where T : P {
  func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}

This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.

The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write

func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}

In this case, T : P2 is an abstract conformance on the type T.

The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:

protocol P {
  associatedtype T : Q

  func foo()
}

extension P {
  func foo() {}
}

class ConformsWithDefault<T : Q> : P {}

The above used to crash; now it will type-check correctly.

Fixes rdar://problem/44736411, https://bugs.swift.org/browse/SR-8814.

…aints

Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.

For example, consider this code, which we correctly support today:

protocol P {
  associatedtype T : Q
}

protocol Q {}

class SomeClass<U : Q> {}

struct Outer<T> where T : P {
  func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}

The constraint 'T == SomeClass<U>' makes the outer constraint
`T : P' redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint 'U == T.T'.

However, whereas 'T : P' together with 'U == T.T' make 'U : Q'
redundant, the introduction of the constraint 'T == SomeClass<U>'
removes 'T : P', so we re-introduce an explicit constraint 'U : Q'
in order to get a valid generic signature.

This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.

As a result, this case was broken:

struct Outer<T> where T : P {
  func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}

This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.

The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write

func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}

In this case, 'T : P2' is an abstract conformance on the type 'T'.

The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:

protocol P {
  associatedtype T : Q

  func foo()
}

extension P {
  func foo() {}
}

class ConformsWithDefault<T : Q> : P {}

The above used to crash; now it will type-check correctly.

Fixes <rdar://problem/44736411>, <https://bugs.swift.org/browse/SR-8814>..
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov
Copy link
Contributor Author

@swift-ci Please test source compatibility

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marvelous!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants