Find location method and export in SARIF

[xaldama]

What problem are you trying to solve?

SARIF results currently contain no information about which function or method a violation belongs to. Consumers of the SARIF output (e.g. Datadog's static analysis backend) cannot associate a violation with its enclosing function without re-parsing the source file themselves.

What is your solution?

• Adds a method_name field to the Violation model.
• Adds ddsa.getEnclosingFunctionName(node) to the JavaScript runtime API, which walks the tree-sitter AST upward to find the nearest enclosing function or method declaration. It supports all languages covered by the analyzer (Java, Python, JavaScript/TypeScript, Go, Ruby, Kotlin, C#, Rust, and others).
• The Violation constructor automatically calls getEnclosingFunctionName when a TreeSitterNode is passed as the location argument, so existing rules get method_name populated without any changes. Rules can override it explicitly via violation.withMethodName(name).
• When method_name is set, it is emitted in the SARIF output as a logicalLocation with kind: "function".

Alternatives considered

Post-processing the violations on the Rust side using tree-sitter's descendant_for_point_range after JS execution. Discarded in favor of the JS-side approach since the TreeSitterNode is already available at violation creation time and the detection naturally belongs there.

What the reviewer should know

• Rules that create violations using buildError (4 coordinates) or { line, col } positions get no auto-detection, since there is no TreeSitterNode to walk. They can still opt in via withMethodName.
• The test variadic_violation_creation in violation.rs was updated to use new_runtime() instead of deno_core_rt(), because the Violation constructor now invokes op_ts_node_parent which requires the DDSA bridge state.

[Copilot]

Pull request overview

This PR enriches reported violations with the enclosing function/method name and exports that context in SARIF, allowing SARIF consumers to associate findings with functions without re-parsing source.

Changes:

• Add method_name to the Rust Violation model and thread it through the DDSA JS↔Rust conversion layer.
• Auto-detect enclosing function/method names in the DDSA JS runtime via ddsa.getEnclosingFunctionName(node) and auto-populate Violation.methodName during construction (with an explicit withMethodName override).
• Emit method_name into SARIF as a logicalLocation with kind "function" when present.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
crates/static-analysis-kernel/src/model/violation.rs	Adds method_name to the core violation model.
crates/static-analysis-kernel/src/analysis/ddsa_lib/runtime.rs	Adds runtime tests ensuring method_name is auto-populated/overridable.
crates/static-analysis-kernel/src/analysis/ddsa_lib/js/violation.rs	Extends V8 conversion to read/write methodName from JS violations.
crates/static-analysis-kernel/src/analysis/ddsa_lib/js/violation.js	Auto-populates methodName during construction and adds withMethodName.
crates/static-analysis-kernel/src/analysis/ddsa_lib/js/ddsa.js	Introduces getEnclosingFunctionName helper to walk the tree-sitter AST upward.
crates/cli/src/sarif/sarif_utils.rs	Emits logicalLocations in SARIF when method_name is present.
crates/cli/src/rule_utils.rs	Updates violation construction to include method_name: None.
crates/cli/src/file_utils.rs	Updates violation construction in tests to include method_name: None.
crates/cli/src/csv.rs	Updates violation construction in tests to include method_name: None.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.