fix(incremental): seed callee::restName typeMap keys and pass callerName for Phase 8.3f

[carlos-alm]

Summary

• buildCallEdges in the incremental rebuild path (incremental.ts) was missing two things needed for Phase 8.3f scoped-key lookup to work after a file edit:
  1. TypeMap not seeded with scoped keys: objectRestParamBindings × paramBindings were not cross-referenced to seed callee::restName entries (e.g. f2::rest) in the typeMap. Without this seeding the scoped-key fallback in resolveByMethodOrGlobal (typeMap.get(callerName::receiver)) has nothing to find.
  2. caller.callerName not passed: Even with scoped keys in the typeMap, the ${callerName}::${effectiveReceiver} lookup never fired because callerName was not passed to resolveCallTargets.
• Also ports the same-class this.method() fallback and definePropertyReceivers fallback from the full-build path into buildCallEdges, completing incremental/full-build parity for these resolution patterns.

Test plan

• New issue-1369 integration test: full build produces f1→m1 and f2→m2 (same fixture as fix(resolver): scope Phase 8.3f typeMap key by function to avoid same-name rest-param collision #1358); subsequent incremental rebuild (file touch) preserves both edges with no cross-edges
• All three tests (#1336, #1358, #1369) pass locally

Closes #1369

[greptile-apps]

Greptile Summary

This PR fixes two missing pieces in the incremental rebuild path (buildCallEdges in incremental.ts) that caused Phase 8.3f scoped-key resolution to fail after a file edit: the typeMap was not seeded with callee::restName scoped keys, and caller.callerName was not forwarded to resolveCallTargets. It also ports the same-class this.method() fallback and definePropertyReceivers fallback to achieve full parity with the full-build path.

• typeMap seeding: The new loop mirrors buildObjectRestParamPostPass exactly — same confidence value (0.65), same scoped-key guard (!typeMap.has(scopedKey)), same unscoped-key-only-when-singleton logic — so incremental and full-build produce identical entries.
• callerName forwarding: resolveCallTargets now receives caller.callerName, enabling the scoped ${callerName}::${effectiveReceiver} lookup in resolveByMethodOrGlobal that was silently a no-op before.
• Integration test: The new issue-1369 test runs a full build followed by a file-touch incremental rebuild and asserts that both f1→m1 and f2→m2 edges are preserved with no cross-edges, directly covering the regression scenario.

Confidence Score: 5/5

Safe to merge — the changes close a gap where incremental rebuilds silently produced incomplete call graphs for files using shared rest-param names.

The typeMap seeding block is a line-for-line match to buildObjectRestParamPostPass (same confidence constant, same guard conditions, same unscoped-key-when-singleton rule). The callerName forwarding is a one-argument addition to an already-existing call. Both fallbacks are direct ports from the verified full-build path. The integration test covers the exact regression scenario end-to-end.

No files require special attention.

Important Files Changed

Filename	Overview
src/domain/graph/builder/incremental.ts	Added typeMap scoped-key seeding (mirroring buildObjectRestParamPostPass), callerName forwarding, same-class this.method() fallback, and definePropertyReceivers fallback — all faithfully matching the full-build path logic with no obvious divergences.
tests/integration/issue-1369-incremental-rest-param-callerName.test.ts	New integration test using the same fixture as #1358; covers full build followed by incremental rebuild and asserts correct edges with no cross-contamination.

Sequence Diagram

sequenceDiagram
    participant BG as buildGraph (incremental)
    participant BCE as buildCallEdges
    participant TM as typeMap
    participant FC as findCaller
    participant RCT as resolveCallTargets
    participant RBMG as resolveByMethodOrGlobal

    BG->>BCE: symbols (calls, objectRestParamBindings, paramBindings)
    BCE->>TM: seed callee::restName keys (Phase 8.3f)
    note over TM: e.g. f2::rest → { type: obj2 }

    loop for each call
        BCE->>FC: findCaller(call, definitions)
        FC-->>BCE: "caller { id, callerName }"
        BCE->>RCT: resolveCallTargets(..., callerName) ← NEW
        RCT->>RBMG: resolveByMethodOrGlobal(typeMap, callerName)
        RBMG->>TM: typeMap.get("f2::rest") ← scoped key now found
        TM-->>RBMG: "{ type: obj2 }"
        RBMG-->>RCT: targets [m2]
        RCT-->>BCE: "{ targets [m2], importedFrom }"

        alt targets empty AND this.method() call
            BCE->>BCE: same-class fallback: ClassName.methodName lookup
        end
        alt targets empty AND definePropertyReceivers
            BCE->>BCE: definePropertyReceivers fallback
        end
    end

Loading

_{Reviews (4): Last reviewed commit: "Merge remote-tracking branch 'origin/mai..." | Re-trigger Greptile}

[github-actions]

Codegraph Impact Analysis

1 functions changed → 5 callers affected across 2 files

• buildCallEdges in src/domain/graph/builder/incremental.ts:485 (5 transitive callers)

[carlos-alm]

@greptileai