You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Call-site recording: empty spans under //line, and one walker shared by L1 and L3 #26
Describe the bug
Two problems in how call sites are recorded:
Call nodes under //line directives get empty byte spans (was Call nodes under //line directives get empty byte spans #21). In a file with a //line directive, a call node's positions come from the directive-adjusted line:col, but its byte offsets index the real file. Slicing module.source then returns an empty string, e.g. span.bytes[433,433].
L1 and L3 each walk call sites separately (was Share one call-site walker between L1 and L3 #20). L1 records call sites in buildCallSites (internal/syntactic_analysis/symbol_table.go). L3 repeats the same walk in recordedCalls (internal/dataflow/bodynodes.go), and closures are walked twice the same way (buildInnerCallables and closureUnits). L3 matches its calls to L1's call keys by position in that walk. A count check catches a change in the number of calls, but not a change in order with the same count.
To Reproduce
Create a Go file containing //line virtual.y:900:1, followed by a function that makes calls.
Run cango -i <dir> -a 1 -o /tmp/out.
Inspect those call nodes' span.bytes: start equals end.
Expected behavior
span.bytes covers the call's real text in the file. The line:col can stay directive-adjusted or be real, as long as the docs say which.
One shared walker yields call sites and closures in recording order for both L1 and L3, so the two cannot drift apart.
Logs
Observed in the testdata/dataflow/linedir fixture added by PR #16.
Activity
Go L4 interprocedural SDG, VTA dispatch and library stand-ins (#36)