fix(resolver): attribute new ClassName() calls to the constructor method

[carlos-alm]

Summary

new ClassName() (and bare ClassName() in languages with no new keyword) always resolved only to the class declaration node, never to the class's own constructor method, even when the class declared one explicitly. Every constructor in the codebase therefore reported zero dependents via fn-impact/roles --role dead, no matter how many call sites actually constructed the class.

Root cause

• handleNewExpr (JS/TS) and its per-language equivalents emit a bare (no-receiver) call named after the class.
• That bare name always resolves through resolveCallTargets/resolveByGlobal to the class declaration node (stored under the bare name), never to the constructor method (stored under a separate qualified name — ClassName.constructor for JS/TS, ClassName.__init__ for Python, ClassName.ClassName for Java/C#/Dart/Groovy, whose constructor identifier equals the class name).

Fix

resolveCallTargets (src/domain/graph/builder/call-resolver.ts) and resolve_call_targets (crates/codegraph-core/src/domain/graph/builder/stages/build_edges.rs) now additionally resolve the class's own constructor method for any bare call that lands on a class-kind target, and emit a second calls edge to it alongside the existing class-node edge (attachConstructorTargets / attach_constructor_targets in strategy.ts / build_edges.rs).

This is additive, not a replacement: the class-node edge is always kept, because buildChaContextFromDb's RTA fallback (incremental rebuilds, builder/cha.ts) reads instantiation evidence from calls edges targeting class-kind nodes. A class with no explicit constructor still resolves only to the class node — there's nothing else to attribute the call to, and the fix doesn't fabricate an edge.

The constructor's local name is resolved per-language via a small extension-keyed table (mirrored identically in both engines):

Extensions	Constructor identifier
.js .mjs .cjs .jsx .ts .tsx .mts .cts	constructor
.py .pyi	__init__
.php .phtml	__construct
.java .cs .dart .groovy .gvy	same as the class name itself

Kotlin, Swift, and Scala are deliberately excluded — their extractors don't emit an explicit constructor definition at all, so there's nothing to attribute to. C++ is excluded because its extractor doesn't track object-construction call sites at all.

Test plan

• New integration test (tests/integration/issue-1892-constructor-call-attribution.test.ts) covering JS/TS, Python, and Java, on both native and WASM engines: verifies the constructor-method edge is added when a class declares one, and verifies no edge is fabricated when it doesn't.
• Updated the javascript/python/csharp/dynamic-typescript resolution benchmark fixtures — their expected-edges.json ground truth predated this fix and only encoded the class-node edge; the new constructor-method edges are legitimate true positives, not regressions.
• npm test — full suite green except a single pre-existing flake tracked separately (Flaky cycle-node ordering in checkNoNewCycles full-suite run (tests/integration/check.test.ts) #1990), unrelated to this change.
• npm run lint — clean on touched files.
• cargo test — 577 passed. cargo check --workspace / cargo clippy --workspace clean on touched files (pre-existing warnings elsewhere untouched).
• Native addon rebuilt, codesigned, verified directly against both the fix and a reverted baseline to confirm every resolution-benchmark change is a genuine improvement, not a regression.
• codegraph diff-impact --staged -T — contained impact (4 functions changed, 18 transitive callers, all within the resolver).

Out of scope

Found and filed separately while testing, not touched here:

• Python: calls after the first module-level SCREAMING_CASE constant mis-attribute to that first constant #2027 — Python: calls after the first module-level SCREAMING_CASE constant mis-attribute to that first constant (findEnclosingBinding widest-span tie-break collision from missing endLine).

Fixes #1892

[greptile-apps]

Greptile Summary

This PR fixes a longstanding gap where new ClassName() calls (and bare ClassName() in keyword-less languages) resolved only to the class declaration node, never the class's own constructor method — causing every constructor to report zero dependents in fn-impact/roles --role dead. The fix adds a second, additive calls edge to the constructor method node whenever one is explicitly declared, via attachConstructorTargets (TypeScript) and attach_constructor_targets (Rust), without removing the existing class-node edge that the CHA/RTA rebuild pass depends on.

• Dual edge emission: new Foo() now produces both a → Foo (class) edge and a → Foo.constructor (method) edge; classes with no explicit constructor continue to resolve only to the class node.
• CHA guard: isConstructorMethodSuffix is used in both CHA post-passes (runChaPostPass / expandChaEdges) to prevent the new constructor-method edges from being polymorphically expanded to unrelated subclasses' constructors.
• Barrel-rename fix: resolvedClassName is tracked through barrel resolution in resolveCallTargets so a barrel that re-exports Foo as Bar doesn't cause the constructor lookup to search for Bar.constructor in foo.ts instead of Foo.constructor.

Confidence Score: 5/5

Safe to merge. The change is additive — it only appends new edges, never removes existing ones — and the critical invariants are all verified by integration and unit tests.

The implementation correctly handles all three constructor-naming families across both engines. The barrel-rename edge case is explicitly unit-tested. Both CHA post-passes have the constructor-exclusion guard. Benchmark fixtures were updated with the new true-positive edges and will catch any regression.

No files require special attention. Pre-existing Dart extractor limitations are filed as follow-up #2082 and do not affect correctness here.

Important Files Changed

Filename	Overview
src/domain/graph/resolver/strategy.ts	Adds constructor attribution logic: CONSTRUCTOR_LOCAL_NAME_BY_EXTENSION map, constructorLocalName(), resolveConstructorTarget(), attachConstructorTargets(), and isConstructorMethodSuffix(). Extension map and FIXED_CONSTRUCTOR_KEYWORDS set are self-consistent; CTOR_NAME_SAME_AS_CLASS sentinel avoids accidental falsy checks.
src/domain/graph/builder/call-resolver.ts	Introduces resolvedClassName tracking through barrel resolution so the constructor lookup uses the class's true declared name (not the barrel alias); return type widened to include kind?; unit-tested with new barrel-rename regression fixture.
crates/codegraph-core/src/domain/graph/builder/stages/build_edges.rs	resolve_call_targets split into thin wrapper + resolve_call_targets_core; new attach_constructor_targets, resolve_constructor_target, and constructor_local_name mirror their TypeScript counterparts correctly.
src/domain/graph/builder/helpers.ts	Adds isConstructorMethodSuffix guard to runChaPostPass, preventing new constructor-attribution edges from triggering polymorphic CHA expansion to subclass constructors.
src/domain/graph/builder/stages/native-orchestrator.ts	Mirrors the CHA guard from helpers.ts in expandChaEdges for the native-engine path; both CHA post-passes are now symmetric.
tests/integration/issue-1892-constructor-call-attribution.test.ts	Comprehensive regression test covering JS/TS, Python, Java, PHP, Dart, and Groovy — all three naming families, with positive and negative cases for each. Runs on both WASM and native engines.
tests/unit/call-resolver.test.ts	New barrel-rename regression tests verify resolvedClassName tracking: correct attribution through a renaming barrel, and no fabricated edge when barrel-renamed class has no constructor.
src/extractors/dart.ts	Widens handleDartConstructorCall to handle both npm tree-sitter-dart 1.x and crates.io 0.2 AST shapes.
crates/codegraph-core/src/extractors/dart.rs	Rust mirror of the Dart extractor fix for cross-engine parity.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["new ClassName() call site"] --> B["resolveCallTargets / resolve_call_targets"]
    B --> C["resolve_call_targets_core"]
    C --> D{Targets found?}
    D -- No --> E["Return empty"]
    D -- Yes --> F{"Any target kind === 'class'?"}
    F -- No --> G["Return targets as-is"]
    F -- Yes --> H["attachConstructorTargets"]
    H --> I["constructorLocalName(file, className)"]
    I --> J{Language recognised?}
    J -- No --> K["Skip"]
    J -- Yes --> L["Build Foo.constructor / Foo.__init__ / Foo.Foo"]
    L --> M["byNameAndFile lookup filtered to method"]
    M --> N{Constructor found?}
    N -- No --> O["Class-node edge only"]
    N -- Yes --> P["Append ctor node (dedup)"]
    P --> Q["Emit both edges"]
    Q --> R["CHA post-pass: isConstructorMethodSuffix guard skips constructor edges"]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A["new ClassName() call site"] --> B["resolveCallTargets / resolve_call_targets"]
    B --> C["resolve_call_targets_core"]
    C --> D{Targets found?}
    D -- No --> E["Return empty"]
    D -- Yes --> F{"Any target kind === 'class'?"}
    F -- No --> G["Return targets as-is"]
    F -- Yes --> H["attachConstructorTargets"]
    H --> I["constructorLocalName(file, className)"]
    I --> J{Language recognised?}
    J -- No --> K["Skip"]
    J -- Yes --> L["Build Foo.constructor / Foo.__init__ / Foo.Foo"]
    L --> M["byNameAndFile lookup filtered to method"]
    M --> N{Constructor found?}
    N -- No --> O["Class-node edge only"]
    N -- Yes --> P["Append ctor node (dedup)"]
    P --> Q["Emit both edges"]
    Q --> R["CHA post-pass: isConstructorMethodSuffix guard skips constructor edges"]

Loading

_{Reviews (6): Last reviewed commit: "test: close stale java/typescript resolu..." | Re-trigger Greptile}

[greptile-apps]

PHP __construct not covered by any integration test

The extension map in both strategy.ts and build_edges.rs includes .php/.phtml → __construct, but neither the new integration test nor any existing benchmark fixture exercises this path. PHP's constructor convention (__construct) is a fixed keyword (like __init__), unlike the Java/C#/Dart/Groovy "same as class name" pattern, so a typo in the keyword or a mismatch between the TS and Rust arms would go undetected. Dart and Groovy are in the same position.

A minimal fixture analogous to the Python Baz/Qux scenario would validate all three extension families: keyword-fixed (PHP), class-name-identical (Java/C#/Dart/Groovy), and Python-style (__init__). Java is already tested; PHP/Dart/Groovy are not.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[carlos-alm]

Addressed — added PHP (Grault/Garply), Dart (Waldo/Fred), and Groovy (Plugh/Xyzzy) fixtures and positive/negative test cases to the integration test in commit 0ae2ecd (test: cover PHP/Dart/Groovy constructor attribution, close stale dart/php ground truth), covering all three extension families you named: keyword-fixed (PHP __construct), class-name-identical (Java already covered; now also Dart/Groovy), and Python-style (__init__, already covered).

Two things worth calling out from doing this:

1. The Dart fixture had to work around three separate, pre-existing Dart extractor bugs unrelated to constructor attribution (bare keyword-less calls aren't extracted at all, a multi-line function's endLine is truncated to its signature line breaking caller attribution, and a semicolon-only/bodyless constructor isn't extracted as a definition). Filed as follow-up issue Dart extractor: bare keyword-less calls not extracted; multi-line function endLine truncated; bodyless constructors not extracted #2082 rather than fixed here — fixing them properly is a substantial, separate body of work in src/extractors/dart.ts.
2. While verifying the PHP/Dart benchmark fixtures, I found their expected-edges.json ground truth predated this fix too (same issue as the javascript/python/csharp/dynamic-typescript files the original commit updated) — fixed in the same commit. Groovy's benchmark fixture has no explicit constructor in any of its three classes, so there was nothing to update there; its coverage comes entirely from the new integration-test fixture.

[greptile-apps]

!entry guard conflates undefined with empty string

CONSTRUCTOR_LOCAL_NAME_BY_EXTENSION values are string | typeof CTOR_NAME_SAME_AS_CLASS. Map.get() returns undefined when the key is absent. The guard if (!entry) return null would also short-circuit on an empty string "", which cannot appear in the current map but could silently corrupt a future extension entry. Prefer an explicit undefined check to make the intent clear and guard against accidental falsy values.

Suggested change

	const entry = CONSTRUCTOR_LOCAL_NAME_BY_EXTENSION.get(file.slice(dotIdx));
	if (!entry) return null;
	const entry = CONSTRUCTOR_LOCAL_NAME_BY_EXTENSION.get(file.slice(dotIdx));
	if (entry === undefined) return null;

[carlos-alm]

Fixed as suggested — changed the guard to an explicit entry === undefined check in commit 5733055 (fix: use explicit undefined check for CONSTRUCTOR_LOCAL_NAME_BY_EXTENSION lookup). Agreed this is the right defensive-coding call: !entry conflating an absent key with a future empty-string value is a real (if currently latent) footgun, and the explicit check costs nothing.

[greptile-apps]

targets declared without kind, but attachConstructorTargets relies on it at runtime

targets is typed as ReadonlyArray<{ id: number; file: string }> (no kind), so resolved inherits that narrower type. When attachConstructorTargets is called, TypeScript infers T = { id: number; file: string }, satisfying the generic constraint only because kind is optional in the bound. At runtime, the actual objects returned by lookup.byNameAndFile do carry kind, so the target.kind !== 'class' guard inside attachConstructorTargets works correctly. However, if downstream code ever tries to read kind from items of resolved after this call, TypeScript won't catch that access as safe. Widening the targets declaration to include kind?: string would close the gap.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[carlos-alm]

Fixed as suggested — widened resolveCallTargets's declared return type (and the internal targets variable) to Array<{ id: number; file: string; kind?: string }> in commit e6f2e1c (fix: widen resolveCallTargets's targets type to include kind). This also let me delete a workaround cast in build-edges.ts's resolveFallbackTargets (the value-ref kind filter) that existed specifically because of this exact gap — that cast's own comment called out "the same gap" you're flagging here, so closing it at the source removed the need for the workaround entirely.

[github-actions]

Codegraph Impact Analysis

9 functions changed → 28 callers affected across 8 files

• resolveCallTargets in src/domain/graph/builder/call-resolver.ts:264 (15 transitive callers)
• runChaPostPass in src/domain/graph/builder/helpers.ts:621 (3 transitive callers)
• resolveFallbackTargets in src/domain/graph/builder/stages/build-edges.ts:1271 (3 transitive callers)
• expandChaEdges in src/domain/graph/builder/stages/native-orchestrator.ts:845 (3 transitive callers)
• constructorLocalName in src/domain/graph/resolver/strategy.ts:107 (3 transitive callers)
• resolveConstructorTarget in src/domain/graph/resolver/strategy.ts:120 (9 transitive callers)
• attachConstructorTargets in src/domain/graph/resolver/strategy.ts:148 (12 transitive callers)
• isConstructorMethodSuffix in src/domain/graph/resolver/strategy.ts:198 (6 transitive callers)
• handleDartConstructorCall in src/extractors/dart.ts:243 (2 transitive callers)

[carlos-alm]

Addressing the gap called out in your Summary (the "one gap" lowering confidence below 5/5 — constructor attribution not firing when a class is imported through a renaming barrel):

Confirmed and fixed in commit c7f67cf (fix: use the barrel-resolved true name for constructor attribution). resolveCallTargets was passing the call site's targetName (the barrel-aliased name, e.g. Bar) to attachConstructorTargets instead of the name lookup.resolveBarrel itself resolved to (the class's true declared name, e.g. Foo) — so the qualified ClassName.ctorLocalName lookup built a key like Bar.constructor that could never match the actually-stored Foo.constructor. Now tracks the barrel-resolved name separately (resolvedClassName) and uses that for constructor attribution. Added two regression tests in tests/unit/call-resolver.test.ts (positive: barrel-renamed class with a constructor; negative: barrel-renamed class with no constructor, confirming no fabrication).

On your file-table note that build_edges.rs has "the same barrel-rename limitation" — I looked into this and it's not quite symmetric: resolve_call_targets_core in the Rust engine has no barrel-hop resolution tier at all for calls edges (unlike resolveCallTargets's explicit isBarrel/resolveBarrel fallback) — its barrel-handling code is scoped to import-edge emission, a different edge kind. So there's no equivalent one-line fix to mirror here; a real fix would mean adding a whole new resolution tier to the Rust engine, which is a separate, broader, pre-existing gap unrelated to this PR's constructor-attribution feature (and not something #2028's own commit introduced or worsened, since it reuses the same imported_original_names primitive the rest of Rust's call resolution already relies on). Filed as follow-up issue #2083 rather than expanding this PR's scope.