Is your feature request related to a problem? Please describe.
The four interprocedural value verbs are refused on a Java graph, behind a probe for whether any dependence edge touches an SDG port. The refusal was correct: codeanalyzer-java emitted the port vertices and the param_in/param_out/summary lattice between them, but no ddg edge ever touched a port, so slice_forward from a parameter returned the seed alone, paths_between returned no paths, and flows_to_call/flows_to_argument returned False for every input — an empty answer indistinguishable from "no flow exists".
codeanalyzer-java 3.0.3 fixes it (codeanalyzer-java#227, PR codeanalyzer-java#230). The analyzer now emits @formal_in:k → use, return → @formal_out, statement → <call>/actual_in:i and <call>/actual_out → statement, so the port layer is joined to the statement graph in both directions. The same release also drops ddg edges whose endpoint is not a body node (codeanalyzer-java#228), which removes the only measured disagreement between analysis.json and the Neo4j projection.
Measured on daytrader8 at -a 4 with 3.0.3: 5,108 ddg edges touch a port (0 before), formal_in ports with out-degree zero fall from 1,176 to 140 (all 140 are parameters no statement reads), 0 dangling endpoints, and JSON and graph both report 10,493 ddg edges.
Describe the solution you'd like
Describe alternatives you've considered
Not stated in the original issue.
Additional context
Scope boundary
In scope: move the codeanalyzer-java pin to 3.0.3, confirm the port-edge probe passes on its own, remove the refusal so the four verbs answer on Java, and regenerate any committed Java -a 4 fixtures (ddg roughly doubles).
Out of scope: the analyzer-side work (shipped); the wheel/JVM uptake (#339); the pin-vs-releases/latest release mechanism (#336).
Caveats and known risks
- The attachment of
actual_in/actual_out is deliberately coarse: every actual of a call site is fed by the one statement containing it, not by the reaching definition of that particular argument. Paths are complete; per-argument precision needs the statement's own incoming edges. Do not assert a tighter shape than the analyzer promises.
- Under
--l3-engine wala there are no @entry edges to mirror, so formal_in ports stay unattached on that engine. If the SDK ever selects that engine, the probe must keep gating there.
- 140
formal_in ports still have out-degree zero on daytrader8 — unread parameters. A probe asserting "every port is attached" would fail on correct output.
Definition of done
- The four verbs return non-empty, correct answers on a Java fixture where a value crosses two call boundaries, and the same query over Neo4j agrees with the JSON backend
- The gate/probe code path that refused them is gone or narrowed to the wala-engine case, with a test covering the reason it stays
Is your feature request related to a problem? Please describe.
The four interprocedural value verbs are refused on a Java graph, behind a probe for whether any dependence edge touches an SDG port. The refusal was correct: codeanalyzer-java emitted the port vertices and the
param_in/param_out/summarylattice between them, but noddgedge ever touched a port, soslice_forwardfrom a parameter returned the seed alone,paths_betweenreturned no paths, andflows_to_call/flows_to_argumentreturnedFalsefor every input — an empty answer indistinguishable from "no flow exists".codeanalyzer-java 3.0.3 fixes it (codeanalyzer-java#227, PR codeanalyzer-java#230). The analyzer now emits
@formal_in:k → use,return → @formal_out,statement → <call>/actual_in:iand<call>/actual_out → statement, so the port layer is joined to the statement graph in both directions. The same release also dropsddgedges whose endpoint is not a body node (codeanalyzer-java#228), which removes the only measured disagreement betweenanalysis.jsonand the Neo4j projection.Measured on daytrader8 at
-a 4with 3.0.3: 5,108ddgedges touch a port (0 before),formal_inports with out-degree zero fall from 1,176 to 140 (all 140 are parameters no statement reads), 0 dangling endpoints, and JSON and graph both report 10,493ddgedges.Describe the solution you'd like
codeanalyzer-java==3.0.3; the probe passes without a special caseslice_forwardfrom a parameter,paths_between,flows_to_callandflows_to_argumentanswer on a Java graph, over both the JSON and the Neo4j backendDescribe alternatives you've considered
Not stated in the original issue.
Additional context
Scope boundary
In scope: move the
codeanalyzer-javapin to 3.0.3, confirm the port-edge probe passes on its own, remove the refusal so the four verbs answer on Java, and regenerate any committed Java-a 4fixtures (ddgroughly doubles).Out of scope: the analyzer-side work (shipped); the wheel/JVM uptake (#339); the pin-vs-
releases/latestrelease mechanism (#336).Caveats and known risks
actual_in/actual_outis deliberately coarse: every actual of a call site is fed by the one statement containing it, not by the reaching definition of that particular argument. Paths are complete; per-argument precision needs the statement's own incoming edges. Do not assert a tighter shape than the analyzer promises.--l3-engine walathere are no@entryedges to mirror, soformal_inports stay unattached on that engine. If the SDK ever selects that engine, the probe must keep gating there.formal_inports still have out-degree zero on daytrader8 — unread parameters. A probe asserting "every port is attached" would fail on correct output.Definition of done