[4.1] [GSB] Always ensure that we wire up typealiases in protocol extensions. #15014
Conversation
This file contains 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
Member
DougGregor
commented
Mar 6, 2018
DougGregor
commented
- Explanation: Typealiases within protocol extensions have been used as a hack to achieve same-type constraints on associated types from inherited protocols since Swift 3(ish). Swift 4 brought where clauses for associated types and protocols, which eliminated the need for this hack, but some of this pattern still persists. When the associated type comes from an inherited protocol and the typealias is in a protocol extension, we would miss the same-type constraint (sometimes) and could crash in IR generation with no compiler diagnostics.
- Scope: Type checking of generics. Potentially affects any project putting typealiases into protocol extensions, a command (although somewhat dated) pattern. In SR-7097, this showed up as a regression from 4.0 in a project that makes use of Vapor.
- Risk: Medium-low. This establishes additional same-type constraints among same-named types. There are a few possible risks here: new warnings because this code is using older patterns (rather than proper language support for same-type constraints), new constraints that could break existing (incorrectly-accepted) code by properly diagnosing that code as wrong, or other failures due to, e.g., more name lookup along this path. More warnings are the most likely and also most benign; the other failure modes are speculative but possible.
- Testing: Compiler regression tests, built the affected project
- Reviewer: @slavapestov
- Radar: SR-7097 / rdar://problem/38001269
During "expansion" of the requirements of a protocol, we check all of the inherited associated types against definitions within the protocol. Also look for concrete types within extensions of that protocol, so we can identify more places where developers have used typealiases in inheriting protocols to effect a same-type constraint on an inherited associated type. Fixes SR-7097 / rdar://problem/38001269.
DougGregor
requested review from
xedin and
huonw
and removed request for
xedin and
huonw
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please nominate |
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.