From all the other STAL-1960 PRs, we've implemented all the ddsa JsRuntime's core logic and plumbing, but the components aren't yet connected in a way that can execute a rule.
What is your solution?
Several lightweight commits follow the exact same pattern: add some boilerplate to expose a "bridge" via the v8 global object, and then add any relevant tests if there were interlinked components that depending on that bridge.
From there, we implement execute_rule_internal (and the friendly, public version: execute_rule).
Sidenote: execute_rule_internal could probably use a slightly nicer function signature. There are a number of things I would like to do here, but they should be handled in a future PR. For example, source_text, source_tree, and language should really all be bundled into a single struct.
Notable technical details
O(N) -> O(1): v8::Script cache: the runtime now transparently maintains a cache of pre-compiled v8::UnboundScript, so we only have v8 compile a rule's code to bytecode once per rule, instead of once per execution, like we did previously.
O(N) -> O(1): tree_sitter::QueryCursor re-use We take advantage of the hook we introduced in https://github.com/DataDog/datadog-static-analyzer/pull/366 to create a tree_sitter::QueryCursor once per process, instead of once per execution, like we did previously.
The extra code we wrap the rule with is now very simple thanks to all of the complexity handled on the Rust end.
Alternatives considered
What the reviewer should know
All that's left now is a single PR that completely switches all use of stella to ddsa. This will effectively be "drop in", where we will use ddsa_lib::JsRuntime::execute_rule instead of our current use of analysis::javascript::execute_rule.
What problem are you trying to solve?
From all the other STAL-1960 PRs, we've implemented all the ddsa JsRuntime's core logic and plumbing, but the components aren't yet connected in a way that can execute a rule.
What is your solution?
Several lightweight commits follow the exact same pattern: add some boilerplate to expose a "bridge" via the v8 global object, and then add any relevant tests if there were interlinked components that depending on that bridge.
From there, we implement
execute_rule_internal(and the friendly, public version:execute_rule).Sidenote:
execute_rule_internalcould probably use a slightly nicer function signature. There are a number of things I would like to do here, but they should be handled in a future PR. For example,source_text,source_tree, andlanguageshould really all be bundled into a single struct.Notable technical details
O(N) -> O(1): v8::Script cache: the runtime now transparently maintains a cache of pre-compiledv8::UnboundScript, so we only have v8 compile a rule's code to bytecode once per rule, instead of once per execution, like we did previously.O(N) -> O(1): tree_sitter::QueryCursor re-use We take advantage of the hook we introduced in https://github.com/DataDog/datadog-static-analyzer/pull/366 to create atree_sitter::QueryCursoronce per process, instead of once per execution, like we did previously.scoped_executeabstraction introduced in https://github.com/DataDog/datadog-static-analyzer/pull/398.Alternatives considered
What the reviewer should know
ddsa_lib::JsRuntime::execute_ruleinstead of our current use ofanalysis::javascript::execute_rule.