JS: support flow out of "this" in constructor call #765
Conversation
ghost
added
the
|
The evaluation from the parent PR should still apply as it includes this commit. |
| or | ||
| exists(Function f, DataFlow::Node mid, DataFlow::Node base | | ||
| exists(Function f, DataFlow::Node mid | | ||
| // `f` stores its parameter `pred` in property `prop` of a value that it returns, |
There was a problem hiding this comment.
Comment needs to be generalised slightly since we're no longer requiring that the value is returned.
There was a problem hiding this comment.
Do we need a concomitant change in TrackedNodes.qll?
| /** | ||
| * Holds if `f` may return `base`, which has a write of property `prop` with right-hand side `rhs`. | ||
| */ | ||
| predicate receiverPropWrite(Function f, string prop, DataFlow::Node rhs) { |
There was a problem hiding this comment.
I moved this as well as returnedPropWrite into FlowSteps.qll so they are private and can be shared with TrackedNode.qll.
Technically this is breaking since DataFlow::returnedPropWrite was public and not marked as internal. But it's kind of an obscure thing to try and use from the outside, so rather than deprecating it I think a change note should suffice in this case, WDYT?
There was a problem hiding this comment.
Definitely; that predicate being public was an oversight.
| exists(Function f | calls(succ, f) | | ||
| returnExpr(f, pred, _) | ||
| or | ||
| succ instanceof DataFlow::NewNode and |
There was a problem hiding this comment.
Again, perhaps worth generalising the doc comment to explain about this case.
asger-semmle
force-pushed
the
class-receiver-propagation
branch
from
f8b4bbd to
a1c7f32
Compare
|
Rebased to resolve conflicts, PTAL overall. |
2 participants
The first commit from #760