Swift: dataflow for for-in loops#13909
Conversation
|
This is built on top of #13838 - only the last two commits are new |
geoffw0
left a comment
There was a problem hiding this comment.
This is pleasingly straightforward!
I'd like to see iteration through CollectionElement supported + tested in addition to ArrayContent.
|
Actually after starting on dictionaries I'm no longer sure this is the right way to do this - I think there's an implicit call that generates an iterator or something, and this PR won't capture the behavior of dictionaries properly. |
|
After rethinking how dictionary flow is implemented I think this will work properly for dictionaries. There's still some weirder options (self-iterators and such) that won't be handled. |
e942019 to
1e0f410
Compare
geoffw0
left a comment
There was a problem hiding this comment.
I'm happy with this, I think you just need to finish the discussion with @MathiasVP and probably do a DCA run.
7026eb2 to
988a871
Compare
|
Is there anything I can do to help get this mergeable / merged? |
|
#14119 broke the original version of the PR, and I decided to go ahead and handle the iterator semantics directly rather than doing a short-term workaround. The QL needs a re-review and there's some extractor changes in a3e250a that I'd like @AlexDenisov's review on. There's likely to be a small test conflict with #14205, so it's probably best to get that out of the way. |
2f0f3f6 to
e0fae76
Compare
C++ change looks good! |
|
I'm unable to reproduce the new |
|
I haven't been able to reproduce it either... Not sure what's going on there. |
|
... and indeed the new result does not appear on the second DCA run. I'm inclined not to worry about it any further, at least with regards to this PR. |
geoffw0
left a comment
There was a problem hiding this comment.
I've just done a quick re-review, including a very brief test of the upgrade script for myself (focussing on AST intactness). I'm happy.
Might be good to wait for a 👍 from @MathiasVP as well.
MathiasVP
left a comment
There was a problem hiding this comment.
A couple of comments. Mostly for my own understanding.
| ) | ||
| } | ||
|
|
||
| // TODO: do we need a new_apply_expr_arguments |
There was a problem hiding this comment.
What's the status of this TODO?
There was a problem hiding this comment.
We don't need it - the this parameter is part of new_self_apply_exprs.
| fillLabeledStmt(stmt, entry); | ||
| entry.body = dispatcher.fetchLabel(stmt.getBody()); | ||
| entry.sequence = dispatcher.fetchLabel(stmt.getTypeCheckedSequence()); | ||
| // entry.sequence = dispatcher.fetchLabel(stmt.getTypeCheckedSequence()); |
There was a problem hiding this comment.
Hmm... Isn't the sequence the xs in:
for i in xs { /* ... */ }do we no longer extract this expression then?
There was a problem hiding this comment.
Oh, looking at the PrintAST test I now see what's going on. Instead of being able to do myLoop.getSequence() you should now do myLoop.getIteratorVar().getInit(). Is that right?
If so, we should probably (in a future PR) add a convenience predicate on ForEachStmt.
There was a problem hiding this comment.
That actually makes the change note easier to write (and no need for a deprecation), so I'll go ahead and do it as part of this.
Co-authored-by: Mathias Vorreiter Pedersen <mathiasvp@github.com>
Fix conflict in AST test output
MathiasVP
left a comment
There was a problem hiding this comment.
LGTM once the code is formatted!
geoffw0
left a comment
There was a problem hiding this comment.
LGTM too (when the checks pass)!
No description provided.