fix(extraction): index TypeScript interface members (#1638) - #1780
Merged
Merged
Conversation
Land upstream #1686 (maxmilian + bompus kernel/CG-28 follow-ups) onto current main. tree-sitter-typescript interface members (method_signature / property_signature) were never listed in the TS extractor, so platform .d.ts APIs had no declaration nodes for call edges. Mirrors on the Rust kernel path; keeps CG-28 damping for pure-interface declaration files; filters damped files from the explore RWR seed set.
Dshuishui
added a commit
to Dshuishui/codegraph
that referenced
this pull request
Sep 14, 2026
…nry#1784) `extension_type_declaration` appears in none of the three places Dart's other type-like declarations do. `extension_declaration` — the older `extension` — is in all three, and the two names are near neighbours. That is why colbymchenry#1780's `isInsideClassLikeNode()` gate dropped these members and no others: the gate asks whether a class-like node is on the stack, and an `extension type` never put one there, while `extension`, `mixin` and `class` all did. The gate surfaced the omission rather than causing it. Before it, the members were still reached — but as top-level `function:km` rather than `method:MetersT::km`, indexed and attributed to nothing. The kernel omits the same node type, so it walks the members through its own fallback and mints them as top-level functions with no `MetersT` to belong to. `kernel-dart-parity.test.ts` fails four cases on `main` because of it; fixing only the wasm side would leave those red. Listing it alongside the others is the whole fix — `extraClassNodeTypes` and `dartEnclosingTypeName` on the wasm side, the two `matches!` arms on the kernel's. Both paths now give: class:MetersT · method:MetersT::km · method:MetersT::report with `report`'s span running to its closing brace rather than stopping at the signature line, and an ordinary class untouched.
Dshuishui
added a commit
to Dshuishui/codegraph
that referenced
this pull request
Sep 14, 2026
…nry#1784) `extension_type_declaration` appears in none of the three places Dart's other type-like declarations do. `extension_declaration` — the older `extension` — is in all three, and the two names are near neighbours. That is why colbymchenry#1780's `isInsideClassLikeNode()` gate dropped these members and no others: the gate asks whether a class-like node is on the stack, and an `extension type` never put one there, while `extension`, `mixin` and `class` all did. The gate surfaced the omission rather than causing it. Before it, the members were still reached — but as top-level `function:km` rather than `method:MetersT::km`, indexed and attributed to nothing. The kernel omits the same node type, so it walks the members through its own fallback and mints them as top-level functions with no `MetersT` to belong to. `kernel-dart-parity.test.ts` fails four cases on `main` because of it; fixing only the wasm side would leave those red. Listing it alongside the others is the whole fix — `extraClassNodeTypes` and `dartEnclosingTypeName` on the wasm side, the two `matches!` arms on the kernel's. Both paths now give: class:MetersT · method:MetersT::km · method:MetersT::report with `report`'s span running to its closing brace rather than stopping at the signature line, and an ordinary class untouched.
Dshuishui
added a commit
to Dshuishui/codegraph
that referenced
this pull request
Sep 15, 2026
…nry#1784) `extension_type_declaration` appears in none of the three places Dart's other type-like declarations do. `extension_declaration` — the older `extension` — is in all three, and the two names are near neighbours. That is why colbymchenry#1780's `isInsideClassLikeNode()` gate dropped these members and no others: the gate asks whether a class-like node is on the stack, and an `extension type` never put one there, while `extension`, `mixin` and `class` all did. The gate surfaced the omission rather than causing it. Before it, the members were still reached — but as top-level `function:km` rather than `method:MetersT::km`, indexed and attributed to nothing. The kernel omits the same node type, so it walks the members through its own fallback and mints them as top-level functions with no `MetersT` to belong to. `kernel-dart-parity.test.ts` fails four cases on `main` because of it; fixing only the wasm side would leave those red. Listing it alongside the others is the whole fix — `extraClassNodeTypes` and `dartEnclosingTypeName` on the wasm side, the two `matches!` arms on the kernel's. Both paths now give: class:MetersT · method:MetersT::km · method:MetersT::report with `report`'s span running to its closing brace rather than stopping at the signature line, and an ordinary class untouched.
inth3shadows
added a commit
to inth3shadows/codegraph
that referenced
this pull request
Sep 23, 2026
…ymchenry#1784) Dart spells an ordinary implemented method `method_signature` — the same node type TypeScript uses for a bodiless interface member. colbymchenry#1780 gated that node type behind isInsideClassLikeNode() to stop a TS interface member minting a phantom free function. Correct for TS, but a Dart 3 `extension type` body was not class-like, so every member in one failed the gate and was dropped. The declaration itself was missing too, not only its members: on main, extension type Meters(double value) { double get km => value / 1000; void show() { print(km); } } extracts `function:show` alone — no `Meters`, no `km`. So `extension type` was never a class-like node in the first place; colbymchenry#1780 only made the omission visible by making the members depend on it. Adding `extension_type_declaration` to Dart's extraClassNodeTypes fixes both halves at once, and gives the members the right owner: `method:Meters::km` rather than a loose top-level `km`. MIRRORED INTO THE KERNEL. Dart is default-routed to the native kernel, so a change made only in the TypeScript arm would not run in a published bundle — and here the two arms had already diverged: the kernel still emitted `function:km` while wasm emitted nothing, which is why kernel-dart-parity is RED on main today. dart.rs listed the class-like node types in two places (enclosing_type_name and the extract dispatch); both now include it. That parity suite is the regression pin this already had — it just never runs without a staged .node, since every kernel-*-parity suite describe.skipIf's itself. From source `npm test` reports 188 skipped; after build-kernel.sh, 10. Verified (Linux, Node 22.23.2, kernel built and staged): kernel-dart-parity 18/18 (4 of these fail on main) dart-extension-type 2/2 (new; both fail without the change) tsc --noEmit clean npm test 252 files, 4373 passed, 3 failed The 3 remaining failures — object-literal-methods and two in ui-steps-api — reproduce on a clean upstream/main worktree and are unrelated. Thanks to the reporter for the diagnosis; this is their suggested option 2, now measured, plus the kernel half.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
maxmilian:fix/1638-ts-interface-members, with @bompus kernel + CG-28 follow-ups) onto currentmain.interfacemembers (method_signature/property_signature) are indexed as methods and properties so platform.d.tsAPIs become addressable.method_signature/property_signaturemissing from the extractor) — every call through a.d.tsplatform API is invisible #1638. Supersedes fix(extraction): index TypeScript interface members (#1638) #1686 (rebase onto current main + CHANGELOG).Linux verify (fail → pass)
Fixture from the issue (
api.d.tswithPlatformContext+ 2 methods + 1 property):main)codegraph initkind:method/kind:propertytenantIdnode deleteQueueCustomAck/tenantIdcontains-linked to the interfaceFocused suites:
explore-declaration-only12/12, extraction interface-member case pass,kernel-tsjs-parity17/17 (earlier run). The store-actions e2e inobject-literal-methodsalready fails on cleanmain(destructuredloginFlowcallers); not a regression from this land.Test plan
main, pass on this branchtsc/ copy-assets