Skip to content

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

Merged
colbymchenry merged 2 commits into
mainfrom
fix/1987-private-field-receiver
Sep 27, 2026
Merged

colbymchenry merged 2 commits into
mainfrom
fix/1987-private-field-receiver

Conversation

@colbymchenry

Copy link
Copy Markdown
Owner

Problem

Built-in calls such as list.map() linked to unrelated project methods. Private-field calls such as this.#items.add() lost their receiver and could resolve as bare method names.

Fix

Build on contributor PR #1990, preserving private-field receivers in both extractors. Require receiver evidence before built-in method names reach capitalization or name-similarity fallbacks. Keep public and private fields with the same spelling distinct. Preserve validated project calls and synthesized dynamic-dispatch flows.

Validation

  • Supplied repro.sh "$PWD": exit 1 before changes; exit 0 after rebuilding, with neither false edge remaining.
  • npm run build:kernel
  • npx tsc && npm run copy-assets
  • npx tsc --noEmit
  • npx vitest run __tests__/js-builtin-method-calls.test.ts __tests__/ts-this-field-call.test.ts __tests__/kernel-tsjs-parity.test.ts __tests__/extraction.test.ts — 741 passed.
  • Neighbor suites passed in npx vitest run __tests__/js-builtin-method-calls.test.ts __tests__/resolution.test.ts __tests__/ts-chained-receiver.test.ts __tests__/call-receiver-no-fabrication.test.ts __tests__/namespace-object-resolution.test.ts __tests__/awaited-receiver.test.ts __tests__/release-main-regressions.test.ts __tests__/dynamic-boundaries.test.ts __tests__/jsx-child-disambiguation.test.ts; the regression suite was subsequently corrected and passed in the focused command above.
  • CODEGRAPH_KERNEL=0 npx vitest run __tests__/js-builtin-method-calls.test.ts __tests__/ts-this-field-call.test.ts — 26 passed.
  • git diff --check

Fixes #1987

🤖 Generated with Claude Code

danusha2345 and others added 2 commits September 27, 2026 08:29
)

A call through an ES private field fell outside the `this.<field>` shape
(#1496): the extractor accepted only a property_identifier, so
`this.#items.add(x)` was emitted as the bare `add` and exact-matched
whichever project method shared the name, often the calling method itself.
The extractor and its kernel mirror now keep `this.#items.add`, and the
resolver matches that shape and reads the field's type off the class
declaration. The field regexes open with a lookbehind instead of `\b`,
which never matches before `#`. A builtin or external field type
(`new Set()`, a `Map`, an array) now yields no edge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…1987)

Unknown JavaScript receivers could match unrelated methods by name or class-name similarity.
Require validated receiver evidence for built-in method names while retaining typed, imported, object-literal and class resolution.
Preserve private-field receivers in TypeScript and Rust extraction and keep public/private field declarations distinct.
Build on PR #1990 with regression coverage across all four JS/TS variants and kernel/WASM parity.

Co-authored-by: danusha2345 <ewidusoc498@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant