Built-in JS/TS methods on untyped values link to project methods with the same name

What happens

A JavaScript/TypeScript call to a built-in method on a value whose type isn't resolved links to any project method with that name:

// src/cart.ts
export class Cart {
  add(item: string): void {}
  map(f: (x: string) => string): string[] { return []; }
}

// src/tidy.ts
export function tidy(list: string[], seen: Set<string>) {
  seen.add('x');
  return list.map((x) => x.trim());
}

After codegraph init, the graph has tidy → Cart::map as calls. list.map is Array.prototype.map. On larger code the same shape links this.#items.add(x) on a Set to a project class's add, so the callers, impact and trace of such a method fill with unrelated call sites.

Why

isUnresolvedJsMemberCall only declines member calls with three or more segments (a.b.c). A two-segment list.map whose receiver can't be typed falls through to the method-name strategies, which accept any same-named method.

Expected

When the receiver's type is unknown and the method is a JavaScript built-in (Array, Map/Set, Promise, String, Function, EventTarget/EventEmitter, iterators), the call stays unresolved. A receiver that is typed still resolves normally.

A fix we're running

Our fork declines those calls when the receiver is not this/super and the method name is in a built-in method table: bompus#151. On our gate corpora it only removed edges to project methods named like built-ins. Happy to open a PR against main if you'd like this direction.

fix(resolution): resolve this.#field.method() on the field's type (co…

Two PRs cover this.

fix(resolution): don't guess project methods for untyped JS built-in method calls #1941 covers the untyped receiver. For a JS/TS built-in method name (Array, Map/Set, String, Promise, RegExp, Object), the name-only fallback now needs the receiver to name a candidate's class, otherwise the call stays unresolved.
fix(resolution): resolve this.#field.method() on the field's type (#1987) #1990 covers this.#items.add(x), which fix(resolution): don't guess project methods for untyped JS built-in method calls #1941 alone missed. A call through an ES private field was emitted as the bare add, so it never reached the typed this.<field> path (TypeScript: a call through this.<field> resolves to the ENCLOSING method when the two share a name — silent self-edge, 0% recall on that shape #1496). It now resolves on the field's declared or constructed type, so a Set field yields no edge.

Checked on the fixture from this issue, plus a Store class with #items = new Set<string>() and put(x) { this.#items.add(x) }:

build	`calls` edges
`main` (`ba3c21e`)	`tidy → Cart::map`, `Store::put → Cart::add`
#1941 (`913fb3f`)	`Store::put → Cart::add`
#1990 (`c0cff45`)	`tidy → Cart::map`
both	none

Merge codex/integration-all-2026-09-26 (colbymchenry#1987, colbymchen…

fix(resolution): require receiver evidence for built-in method calls (#…

@bompus

Thanks for the detailed report, @bompus, and thanks for using CodeGraph! This is fixed on main by #2028, which builds on @danusha2345's #1990 (thank you!): a built-in method call such as list.map(), cache.get() or emitter.emit() on an untyped value no longer links to a project method of the same name, while calls on a constructed, imported, typed or this.#private receiver still resolve. The fix will be in the next release.

Merge upstream/main (71 commits, through e63fe2e) into fork/consolidated

Navigation Menu

Repository navigation

Built-in JS/TS methods on untyped values link to project methods with the same name #1987

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Built-in JS/TS methods on untyped values link to project methods with the same name #1987

Description

Activity

danusha2345 commented on Sep 27, 2026

colbymchenry commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions