JavaScript: Lift call graph library to data flow graph. #15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR lifts
CallSite
from the AST to the data flow graph by adding the relevant API toDataFlow::InvokeNode
.Among other things, this necessitates a change in our handling of spread arguments:
InvokeNode.getArgument(i)
is now only defined if there isn't a spread argument at or before positioni
, and similarly forgetNumArgument
. This is different fromInvokeExpr.getArgument
, but I think it's almost always what we want.In addition to AST-based call nodes, we introduce new reflective call nodes representing the reflective call happening at a
.call
or.apply
invocation. I've separated the abstract classes we need to present a unified interface for explicit and reflective calls from the concrete classes we use to classify the various kinds of calls and invocations. In particular, this allows us to keepInvokeNode
and its subclasses concrete.There is a performance overhead (internal link). The source of the slowdown wasn't obvious from the logs, so I tried adding a bit of explicit caching here and there, but none of that made any difference. I still have a few more ideas, but for now perhaps we'll need to merge this as-is to unblock further data flow graph development.
Results are almost unchanged, except for two new TPs that arise from the fact that we now allow ourselves to interpret
f.apply
as a call to a methodapply
off
if it exists (previouslyReflectiveCallSite
overrodegetACallee
, causing us to always consider it as a reflective call).