[TypeChecker] Rework type-checking of for-in statements
#59003
Merged
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
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
|
@swift-ci please test macOS platform |
|
@swift-ci please test Linux platform |
Previously for-in target was actually an expression target, which means certain type-checking behavior. These changes make it a standalone target with custom behavior which would allow solver to introduce implicit `makeIterator` and `next` calls and move some logic from SILGen.
… targets The dependency on target being an expression is artificial, `typeCheckForCodeCompletion` is capable of type-checking any type of target.
Use newly updated `forEachStmt` target to handle for-in statement preamble when it appears in a multi-statement closure.
Using `typeCheckTarget` removes almost all the duplicate logic.
Use a conformance reference recorded in a `ForEachStmt` by the type-checker, instead of trying to look it up again.
The actual issue in this cases is that the type of a sequence doesn't conform to `Sequence` protocol.
Instead of asking SILGen to build calls to `makeIterator` and `$generator.next()`, let's synthesize and type-check them together with the rest of for-in preamble. This greatly simplifies interaction between Sema and SILGen for for-in statements.
The actual issue in this cases is that the type of a sequence doesn't conform to `Sequence` protocol, which means that it's impossible to deduce a base for `next` call.
Implicitly generated code requires checking but it doesn't have to produce a diagnostic into the void.
This allows to use `for-in` statement to iterate over i.e. `any Collection` and other existentials that conform to `Sequence` protocol.
…ions Just like `any Collection`, it should be possible to use `any Sequence` to iterate over.
Don't so would disconnect $generator from `.next()` call which have to be solved together because they sometimes depend on the for-in pattern to infer the element type.
|
@swift-ci please test |
slavapestov
approved these changes
Jun 1, 2022
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
|
@swift-ci please test source compatibility |
2 similar comments
|
@swift-ci please test source compatibility |
|
@swift-ci please test source compatibility |
ahoppen
added a commit
to ahoppen/swift-source-compat-suite
that referenced
this pull request
Jun 8, 2022
- swiftlang/swift#59315 was introduced by swiftlang/swift#59003
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.
Change the way how
for-instatements are type-checked, where a lot ofinformation has to be recorded in a statement in order for SILGen to generate
appropriate calls to
makeIteratorandnextwitnesses.Instead of just finding a witness, solver would now:
$generator = <sequence>.makeIterator();$generator.next()which is called by each loop iteration;next()Doing so significantly simplifies SILGen, removes the need to carry type information
in
ForEachStmtand enables iterating over existential types.Resolves: rdar://92177656