fix: track class instantiation (new) as consumption

[carlos-alm]

Summary

• new ClassName() was not tracked as a call site by either engine, causing all instantiated classes (e.g. error hierarchy in shared/errors.ts) to appear dead with 0 consumers
• Added new_expression extraction in both WASM (query + walk paths) and native Rust engines, creating calls entries identical to regular call_expression
• Added test covering simple instantiation, throw-context, and member-expression constructors (new ns.Bar())

Details

Root cause: The WASM extractor's COMMON_QUERY_PATTERNS only matched call_expression nodes, and the walk-based fallback's switch only handled call_expression. The native Rust engine's match_js_node similarly only dispatched call_expression to handle_call_expr.

Fix (4 files):

File	Change
src/domain/parser.ts	Added 2 tree-sitter query patterns for new_expression with identifier and member_expression children
src/extractors/javascript.ts	Added dispatch for newfn_node/newmem_node in query path; added handleNewExpr + new_expression case in walk path
crates/codegraph-core/src/extractors/javascript.rs	Added new_expression → handle_new_expr in match_js_node; new handler extracts constructor name and pushes to symbols.calls
tests/parsers/javascript.test.ts	New test: extracts class instantiation as calls covering new Foo(), new ns.Bar(), and throw new ParseError()

Note: The native Rust engine changes require a rebuild to take effect. The build-parity integration tests will fail until the native binary is recompiled.

Test plan

• All 32 JS parser tests pass (31 existing + 1 new)
• All 14 query-walk parity tests pass (query and walk paths produce identical results)
• All 9 engine parity tests pass
• 559/561 integration tests pass (2 build-parity failures expected until native rebuild)
• Lint clean

Closes #836

[claude]

Claude finished @carlos-alm's task —— View job

---

PR Review Complete

Reviewing PR #861: "fix: track class instantiation (new) as consumption"

Tasks:

• Phase 1: Root Cause Analysis
• Phase 2: Configuration Change Detection
• Phase 3: Test Integrity Review
• Phase 4: Code Quality Review
• Phase 5: Backlog Compliance Assessment
• Final Assessment and Rating

Phase 4: Code Quality Review ✅

Implementation Quality: The fix is well-implemented across both engines:

WASM Engine Changes (src/domain/parser.ts:146-147):

• ✅ Correctly adds two new query patterns: (new_expression (identifier) @newfn_name) @newfn_node and (new_expression (member_expression) @newmem_fn) @newmem_node
• ✅ Patterns follow existing conventions and naming schemes (newfn_* / newmem_*)

JavaScript Extractor Changes (src/extractors/javascript.ts:285-296):

• ✅ Query dispatch adds handlers for newfn_node and newmem_node capturing constructor calls identically to regular calls
• ✅ Walk path adds new_expression case in handleNewExpr function (line 532)
• ✅ Consistent extraction logic using existing extractCallInfo helper for member expressions
• ✅ Proper line number extraction and receiver handling

Native Rust Engine Changes (crates/codegraph-core/src/extractors/javascript.rs:116,315-335):

• ✅ Adds new_expression → handle_new_expr dispatch in match_js_node
• ✅ New handler extracts constructor name for both identifier and member expression cases
• ✅ Uses same Call struct and field mapping as regular function calls
• ✅ Consistent with existing code patterns and error handling

Test Coverage (tests/parsers/javascript.test.ts:62-73):

• ✅ Comprehensive test covering simple instantiation, throw context, and member expressions
• ✅ Validates both name extraction and receiver detection for namespaced constructors
• ✅ Integrates well with existing test structure

Engine Parity Compliance: Per CLAUDE.md requirement that "both engines must produce identical results," this PR ensures:

• ✅ Both WASM and native engines now handle new_expression nodes
• ✅ Identical output structure (calls array with same fields)
• ✅ Covered by existing parity tests in tests/engines/parity.test.ts

No Security Concerns: Pure parser enhancement with no external inputs or security implications.

Phase 5: Backlog Compliance Assessment ✅

Zero-dep: ✅ - No new runtime dependencies added. Builds on existing tree-sitter/SQLite infrastructure.

Foundation-aligned: ✅ - Fully compliant with core principles:

• P1 (always-current): Improves accuracy of current codebase analysis
• P4 (zero-cost core): No runtime overhead, pure extraction enhancement
• P5 (embeddable-first): Enhances programmatic API without breaking changes
• P8 (we are not an agent): Pure analysis improvement, no code generation

Problem-fit: 5/5 - Directly addresses the core problem: "AI coding assistants waste tokens re-orienting in large codebases, hallucinate dependencies, and miss blast radius."

• Fixes false dead code detection for instantiated classes
• Reduces AI confusion about which classes are actually used
• Improves call graph accuracy for blast radius analysis

Breaking: No - Purely additive. No CLI output format changes, API signature changes, or tool contract modifications.

Tier: 1 (zero-dep ✓ + foundation-aligned ✓)

Root Cause Analysis

Problem Being Solved: Class instantiations (new ClassName()) were not tracked as call sites, causing instantiated classes to appear as dead code with 0 consumers.

Why This Approach: Correctly adds new_expression handling to both engines' extraction logic. Constructor calls are semantically call sites and should be tracked identically to function calls.

Risk Assessment: Very low risk. Well-tested, follows existing patterns, maintains engine parity.

Backlog Compliance

• Zero-dep: ✓ — no new runtime dependencies
• Foundation-aligned: ✓ — improves analysis accuracy without violating principles
• Problem-fit: 5 — directly fixes AI dead code confusion and improves blast radius analysis
• Breaking: No — purely additive changes
• Tier: 1

Final Recommendation

• Rating: ⭐⭐⭐⭐⭐ (5/5)
• Action: APPROVE
• Reasoning: Excellent implementation of a clear bug fix. Comprehensive test coverage, maintains engine parity, follows established patterns, and directly improves the core value proposition of helping AI understand codebases accurately.

---

[greptile-apps]

Greptile Summary

This PR fixes a gap in both the WASM and native Rust extractors where new ClassName() was not recorded as a call site, causing instantiated classes (e.g., the full error hierarchy in shared/errors.ts) to appear dead with zero consumers. The fix is applied symmetrically across all three extraction paths — query, walk, and Rust — and is backed by a new parser test plus updated benchmark expected-edges fixtures.

Confidence Score: 5/5

Safe to merge — the fix is correct, symmetric across all three extraction paths, and the prior constructor: field-anchor concern from the earlier review thread has already been addressed in commit bbe0a33.

All three extraction paths (WASM query, WASM walk, Rust native) are implemented consistently. The new handling of identifier constructors is a direct push (matching the call_expression identifier path), while member-expression constructors reuse extractCallInfo (also matching the existing path). No BUILTIN_GLOBALS filtering discrepancy exists — call_expression tracking also doesn't filter builtins, so the new path is consistent. Test coverage for the new behaviour is solid. The 2 build-parity failures are expected pending a native rebuild and don't indicate a code defect.

No files require special attention.

Important Files Changed

Filename	Overview
src/domain/parser.ts	Added two new_expression tree-sitter query patterns using the constructor: named-field anchor, consistent with the function: convention on neighbouring call_expression patterns
src/extractors/javascript.ts	Added newfn_node/newmem_node dispatch in the query path and handleNewExpr + new_expression case in the walk path; both paths are structurally consistent with the existing call_expression handling
crates/codegraph-core/src/extractors/javascript.rs	Added new_expression => handle_new_expr dispatch in match_js_node; the new handler extracts the constructor identifier or member-expression and pushes a Call entry, mirroring the WASM path
tests/parsers/javascript.test.ts	New test covers simple instantiation (new Foo()), throw-context (throw new ParseError()), and member-expression constructor (new ns.Bar()) with receiver assertion
tests/benchmarks/resolution/fixtures/javascript/expected-edges.json	Added expected call edges for new UserService() and new Logger() instantiations to reflect the corrected extraction behaviour
tests/benchmarks/resolution/fixtures/typescript/expected-edges.json	Added expected call edges for new JsonSerializer(), new UserRepository(), and new UserService() instantiations
tests/integration/build-parity.test.ts	No logic changes; test auto-skips when native binary is absent, aligning with the expected 2 failures until native rebuild
tests/benchmarks/regression-guard.test.ts	Updated KNOWN_REGRESSIONS and SKIP_VERSIONS sets to reflect current benchmark state; no logic changes to the guard itself

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["JS/TS source file"] --> B["tree-sitter parse"]
    B --> C["AST"]
    C --> D{"Engine"}
    D -->|"WASM query path"| E["COMMON_QUERY_PATTERNS\n+ new_expression patterns"]
    D -->|"WASM walk path"| F["walkJavaScriptNode\nswitch: new_expression"]
    D -->|"Native Rust"| G["match_js_node\nnew_expression"]
    E --> H["dispatchQueryMatch\nnewfn_node / newmem_node"]
    F --> I["handleNewExpr\nidentifier → push call\nmember_expr → extractCallInfo"]
    G --> J["handle_new_expr\nidentifier → push call\nmember_expr → extract_call_info"]
    H --> K["calls: Call[]"]
    I --> K
    J --> K
    K --> L["SQLite edges\nkind = calls"]
    L --> M["Class no longer\nappears dead"]

Loading

_{Reviews (4): Last reviewed commit: "fix(test): add 3.9.0 fnDeps to known reg..." | Re-trigger Greptile}

[greptile-apps]

Missing constructor: field anchor in new_expression patterns

The two new patterns match the constructor child positionally rather than by named field, unlike all neighbouring call_expression patterns which use function:. In practice the anonymous new keyword is never an identifier, so the positional match is correct today, but pinning to the named field is more defensive and consistent with the rest of the file.

Suggested change

	'(new_expression (identifier) @newfn_name) @newfn_node',
	'(new_expression (member_expression) @newmem_fn) @newmem_node',
	'(new_expression constructor: (identifier) @newfn_name) @newfn_node',
	'(new_expression constructor: (member_expression) @newmem_fn) @newmem_node',

[carlos-alm]

Applied. Both patterns now use the named constructor: field anchor (bbe0a33), matching the function: convention on call_expression patterns. The walk paths (WASM + Rust) already used childForFieldName('constructor'), so this brings the query path in line.

[github-actions]

Codegraph Impact Analysis

5 functions changed → 5 callers affected across 2 files

• match_js_node in crates/codegraph-core/src/extractors/javascript.rs:106 (0 transitive callers)
• handle_new_expr in crates/codegraph-core/src/extractors/javascript.rs:315 (1 transitive callers)
• dispatchQueryMatch in src/extractors/javascript.ts:248 (2 transitive callers)
• walkJavaScriptNode in src/extractors/javascript.ts:504 (2 transitive callers)
• handleNewExpr in src/extractors/javascript.ts:721 (3 transitive callers)

[carlos-alm]

@greptileai

[carlos-alm]

@greptileai

[carlos-alm]

@greptileai