Skip to content

Swift: dataflow for for-in loops#13909

Merged
rdmarsh2 merged 35 commits intogithub:mainfrom
rdmarsh2:rdmarsh2/swift/for-in
Oct 9, 2023
Merged

Swift: dataflow for for-in loops#13909
rdmarsh2 merged 35 commits intogithub:mainfrom
rdmarsh2:rdmarsh2/swift/for-in

Conversation

@rdmarsh2
Copy link
Copy Markdown
Contributor

@rdmarsh2 rdmarsh2 commented Aug 7, 2023

No description provided.

@rdmarsh2 rdmarsh2 requested a review from a team as a code owner August 7, 2023 15:11
@rdmarsh2
Copy link
Copy Markdown
Contributor Author

rdmarsh2 commented Aug 7, 2023

This is built on top of #13838 - only the last two commits are new

Copy link
Copy Markdown
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

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

This is pleasingly straightforward!

I'd like to see iteration through CollectionElement supported + tested in addition to ArrayContent.

Comment thread swift/ql/test/library-tests/dataflow/dataflow/test.swift Outdated
@rdmarsh2
Copy link
Copy Markdown
Contributor Author

rdmarsh2 commented Aug 8, 2023

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.

@rdmarsh2 rdmarsh2 closed this Aug 8, 2023
@rdmarsh2
Copy link
Copy Markdown
Contributor Author

rdmarsh2 commented Aug 11, 2023

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.

Comment thread swift/ql/lib/codeql/swift/dataflow/internal/DataFlowPrivate.qll Outdated
Copy link
Copy Markdown
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

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

I'm happy with this, I think you just need to finish the discussion with @MathiasVP and probably do a DCA run.

@geoffw0
Copy link
Copy Markdown
Contributor

geoffw0 commented Sep 13, 2023

Is there anything I can do to help get this mergeable / merged?

@rdmarsh2
Copy link
Copy Markdown
Contributor Author

#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.

@rdmarsh2 rdmarsh2 force-pushed the rdmarsh2/swift/for-in branch from 2f0f3f6 to e0fae76 Compare September 13, 2023 20:09
@AlexDenisov
Copy link
Copy Markdown
Contributor

#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.

C++ change looks good!

Comment on lines +13 to +15
[
";IteratorProtocol;true;next();;;Argument[-1].CollectionElement;ReturnValue.OptionalSome;value"
]

Check warning

Code scanning / CodeQL

Singleton set literal

Singleton set literal can be replaced by its member.
@geoffw0
Copy link
Copy Markdown
Contributor

geoffw0 commented Sep 27, 2023

I'm unable to reproduce the new swift/string-length-conflation result from DCA locally - @rdmarsh2 do you have any idea what's going on with it?

@rdmarsh2
Copy link
Copy Markdown
Contributor Author

I haven't been able to reproduce it either... Not sure what's going on there.

@geoffw0
Copy link
Copy Markdown
Contributor

geoffw0 commented Oct 2, 2023

... 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
geoffw0 previously approved these changes Oct 2, 2023
Copy link
Copy Markdown
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

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

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.

Comment thread swift/ql/lib/change-notes/2023-09-14-for-in-data-flow.md
Copy link
Copy Markdown
Contributor

@MathiasVP MathiasVP left a comment

Choose a reason for hiding this comment

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

A couple of comments. Mostly for my own understanding.

Comment thread swift/ql/lib/codeql/swift/controlflow/internal/ControlFlowGraphImpl.qll Outdated
Comment thread swift/ql/lib/codeql/swift/controlflow/internal/ControlFlowGraphImpl.qll Outdated
)
}

// TODO: do we need a new_apply_expr_arguments
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What's the status of this TODO?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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());
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hmm... Isn't the sequence the xs in:

for i in xs { /* ... */ }

do we no longer extract this expression then?

Copy link
Copy Markdown
Contributor

@MathiasVP MathiasVP Oct 4, 2023

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

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>
MathiasVP
MathiasVP previously approved these changes Oct 4, 2023
Copy link
Copy Markdown
Contributor

@MathiasVP MathiasVP left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Copy Markdown
Contributor

@MathiasVP MathiasVP left a comment

Choose a reason for hiding this comment

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

LGTM once the code is formatted!

geoffw0
geoffw0 previously approved these changes Oct 5, 2023
Copy link
Copy Markdown
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

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

LGTM too (when the checks pass)!

Copy link
Copy Markdown
Contributor

@geoffw0 geoffw0 left a comment

Choose a reason for hiding this comment

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

👍

@rdmarsh2 rdmarsh2 merged commit 8af7277 into github:main Oct 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants