-
Notifications
You must be signed in to change notification settings - Fork 1.9k
ruby/python: Shared module for typetracking through flow summaries #13178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ruby/python: Shared module for typetracking through flow summaries #13178
Conversation
ae32ca9 to
a602abf
Compare
- add `getACallSimple` to `SummarizedCallable` (by adding it to `LibraryCallable`)
ruby: - create new shared file `SummaryTypeTracker.qll` - move much logic into the module - instantiate the module - remove old logic, now provided by module python: - clone shared file - instantiate module - use (some of the) steps provided by the module
a602abf to
820b5f2
Compare
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Fixed
Show fixed
Hide fixed
|
Force-pushed to resolve conflict. (Also added change note.) |
|
It was suggested off-line to also include Java as a user, but it turns out that Java uses type tracking differently and already has flow through summaries. |
asgerf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this! The signature does end up being rather verbose but I guess that's just the way it is. A few minor things otherwise LGTM.
Co-authored-by: Asger F <asgerf@github.com>
|
Thanks for the review, indeed it looks like we can remove those two predicates from the interface. Nice! 💪 |
…uby/track-through-summaries-pm
|
The merge includes the results of https://github.com/github/codeql/pull/12964/files#diff-9547dcadaf57e980b53a87f8f1f5124c65ca46cfe537c69cda27d142078663c1 |
to not use the call graph.
|
So now this PR is ready for review again :-) |
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Outdated
Show resolved
Hide resolved
| ) | ||
| } | ||
|
|
||
| module SummaryTypeTrackerInput implements SummaryTypeTracker::Input { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, that would be nicer.
| Node callTo(SummarizedCallable callable) { result = callable.getACallSimple() } | ||
| } | ||
|
|
||
| module TypeTrackerSummaryFlow = SummaryTypeTracker::SummaryFlow<SummaryTypeTrackerInput>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, yes, the outside does not need this, I think.
| or | ||
| dependsOnSummaryComponentStackCons(callable, _, stack) | ||
| } | ||
| module SummaryTypeTrackerInput implements SummaryTypeTracker::Input { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
| Node callTo(SummarizedCallable callable) { result.asExpr().getExpr() = callable.getACallSimple() } | ||
| } | ||
|
|
||
| module TypeTrackerSummaryFlow = SummaryTypeTracker::SummaryFlow<SummaryTypeTrackerInput>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also private?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
hvitved
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks for making this code shared. I have a few trivial comments. We should also do final DCA runs before merging.
| * These are meant to be used in `TypeTrackerSpecific.qll` | ||
| * inside the predicates of the same names. | ||
| */ | ||
| signature module Output<Input I> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is any need to provide an explicit output signature, when the output is not used itself as input to another parameterized module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might it be in the future, though? If we get type tracking as a parameterised module (as started by Java).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, it is easy enough to add when needed (so we could take it out now), but I actually like how it codifies the intention of the module...
…stSummaries.qll Co-authored-by: Asger F <asgerf@github.com>
- move `isNonLocal` to the top - missing backtics
hvitved
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Let's do a final DCA run before merging.
Agreed, I have kept the |
|
Evaluation looks safe, removing the label (but feel free to disagree). |
python/ql/test/experimental/dataflow/typetracking-summaries/TestSummaries.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/SummaryTypeTracker.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/SummaryTypeTracker.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/SummaryTypeTracker.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/SummaryTypeTracker.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/SummaryTypeTracker.qll
Outdated
Show resolved
Hide resolved
| // Content | ||
| class TypeTrackerContent; | ||
|
|
||
| class TypeTrackerContentFilter; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading the input signature and QLDocs, I have absolutely no idea what the content filters are supposed to do. I guess it'll make sense once I start reading the implementation 🤷
| // Relating nodes to summaries | ||
| Node argumentOf(Node call, SummaryComponent arg) { | ||
| exists(DataFlowDispatch::ParameterPosition pos | | ||
| arg = FlowSummary::SummaryComponent::argument(pos) and | ||
| argumentPositionMatch(call, result, pos) | ||
| ) | ||
| } | ||
|
|
||
| Node parameterOf(Node callable, SummaryComponent param) { | ||
| exists( | ||
| DataFlowDispatch::ArgumentPosition apos, DataFlowDispatch::ParameterPosition ppos, Parameter p | ||
| | | ||
| param = FlowSummary::SummaryComponent::parameter(apos) and | ||
| DataFlowDispatch::parameterMatch(ppos, apos) and | ||
| // pick the SsaNode rather than the CfgNode | ||
| result.asVar().getDefinition().(ParameterDefinition).getParameter() = p and | ||
| ( | ||
| exists(int i | ppos.isPositional(i) | | ||
| p = callable.getALocalSource().asExpr().(CallableExpr).getInnerScope().getArg(i) | ||
| ) | ||
| or | ||
| exists(string name | ppos.isKeyword(name) | | ||
| p = callable.getALocalSource().asExpr().(CallableExpr).getInnerScope().getArgByName(name) | ||
| ) | ||
| ) | ||
| ) | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's talk about these two offline. I would like to understand the interaction with the call-graph a bit better 😊
python/ql/lib/semmle/python/dataflow/new/internal/TypeTrackerSpecific.qll
Outdated
Show resolved
Hide resolved
python/ql/lib/semmle/python/dataflow/new/internal/TypeTrackerSpecific.qll
Outdated
Show resolved
Hide resolved
Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>
…pecific.qll Co-authored-by: Rasmus Wriedt Larsen <rasmuswriedtlarsen@gmail.com>
Shared module provides predicates for
see the output signature.
It is shared via
identicalFiles.jsonand used in ruby and python.Will require performance testing to ensure we did not break ruby performance.
TODO: