JS/Ruby: Represent non-positional arguments with Argument/Parameter tokens#8533
JS/Ruby: Represent non-positional arguments with Argument/Parameter tokens#8533asgerf merged 13 commits intogithub:mainfrom
Conversation
asgerf
force-pushed
the
mad-receiver-token
branch
from
68b86df to
69eb24e
Compare
hmac
left a comment
hmac
left a comment
There was a problem hiding this comment.
I don't feel qualified to comment closely on the implementation, but it seems straightforward and the test changes are what I'd expect. I think I have a slight preference for Receiver over Argument[self] (shorter and matches better with MethodCall.getReceiver) but having consistency between the languages probably trumps that.
The keyword parameter support is really nice!
erik-krogh
left a comment
erik-krogh
left a comment
There was a problem hiding this comment.
JS 👍
(The JS part is simple).
hvitved
left a comment
hvitved
left a comment
There was a problem hiding this comment.
LGTM; two minor comments.
| ) | ||
| or | ||
| pos.isBlock() and | ||
| result = Label::blockParameter() |
There was a problem hiding this comment.
Should the toString of LabelBlockParameter be updated to getParameter(block) (and similar for LabelKeywordParameter? And are we missing labels for the self parameter?
There was a problem hiding this comment.
The toString value of these labels are currently named after predicates on API::Node (not MaD tokens). At least that seemed to be the convention, one that I've tried to continue. So it doesn't need updating.
There was a problem hiding this comment.
At least that seemed to be the convention
I had to give some value for toString() when I introduced IPA types for API-labels.
I decided to use the previous value of the label (which was a string).
The Python labels were named after their predicates on API::Node, so that's what I used.
In JS the toString() are the original labels that Max defined.
There was a problem hiding this comment.
I like having the toString() be the associated predicate on API::Node, so maybe we should update JS to also do that?
| sink(x) | ||
| }) | ||
| Foo.intoNamedParameter(tainted, ->(foo:) { | ||
| sink(foo) |
There was a problem hiding this comment.
We should document that flow is missing in this case
There was a problem hiding this comment.
Dang, I missed that. I'll try to introduce inline assertions to this test.
There was a problem hiding this comment.
Updated to use inline test expectations, much better overall, and it's now clear that this flow is missing.
I haven't investigated why the flow is missing, though. I was under the impression that providing the correct ArgumentPosition and ParameterPosition values would be enough.
There was a problem hiding this comment.
@hvitved would you like it addressed in this PR? Please let me know either way
There was a problem hiding this comment.
No, let's do that follow-up
|
|
||
| from DataFlow::PathNode source, DataFlow::PathNode sink, Conf conf | ||
| where conf.hasFlowPath(source, sink) | ||
| select sink, source, sink, "$@", source, source.toString() |
There was a problem hiding this comment.
I prefer to actually keep this, in addition to import PathGraph, like we do in other flow tests that use InlineFlowTest.
asgerf
force-pushed
the
mad-receiver-token
branch
from
690069d to
0b30ecf
Compare
4 participants
Previously we had separate tokens for non-positional arguments, like
ReceiverandBlockArgument.Now these are represented as operands to
Argument/Parametertokens, as discussed with @hvitved:Ruby:
Argument[self]for the receiver (previouslyReceiver)Argument[block]for the block argument (previouslyBlockArgument)Argument[foo:]for a keyword argument namedfoo(previously not implemented)JS:
Argument[this]for the receiver (previouslyArgument[-1])All of the above also apply to the
Parametertoken.The names
selfandthiswere chosen to coincide with the keyword/convention from the language.