Diagnose unsound uses of same-type-to-Self requirements with non-final classes #9830
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…l classes.
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
protocol Q {
func foo<T: P>(_: T, _: T.T) where T.T == Self
}
class C: Q {
func foo<T: P>(_: T, _: C) where T.T == C {}
}
class D: C {
// in D, T.T == D does not hold
}
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.
|
@swift-ci please smoke test and merge |
|
@DougGregor Nice! This should have resulted in compile-time warnings when compiling ProcedureKit, which is in the compatibility suite now. Do you know if this PR has caught any bugs there? @lplarson Luke do you know if we got any errors/warning about it in ProcedureKit after this PR was merged? |
|
Looks like it did! |
|
@DougGregor I've commented on the radar that eventually we want to make it an error even in Swift 3 compatibility mode. |
DougGregor
added a commit
to DougGregor/swift
that referenced
this pull request
Jun 16, 2017
…ror. Swift 3 had a type soundness hole in protocol conformance checking where the requirement contained an "== Self" constraint and the witness was a member of a non-final class. We previously closed the type soundness hole in PR swiftlang#9830, but left it as a warning in Swift 3 compatibility mode. Escalate that warning to an error. The optimizers break due to this type soundness hole, and of course it can lead to other runtime breakage because it violates the type system. Fixes rdar://problem/28601761.
DougGregor
added a commit
to DougGregor/swift
that referenced
this pull request
Jun 16, 2017
…ror. Swift 3 had a type soundness hole in protocol conformance checking where the requirement contained an "== Self" constraint and the witness was a member of a non-final class. We previously closed the type soundness hole in PR swiftlang#9830, but left it as a warning in Swift 3 compatibility mode. Escalate that warning to an error. The optimizers break due to this type soundness hole, and of course it can lead to other runtime breakage because it violates the type system. Fixes rdar://problem/28601761. (cherry picked from commit 8b80681)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.