fix: attach Go receiver methods to owner types#588
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 90f1a56fe9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (methods.length === 0) return 0; | ||
|
|
||
| const ownersByName = new Map<string, Node[]>(); | ||
| for (const kind of ['struct', 'class', 'enum', 'trait'] as const) { |
There was a problem hiding this comment.
For valid Go defined types whose underlying type is not a struct/interface, e.g. type Status string with func (s Status) String() string in another file, the extractor creates the owner as a type_alias node, but this owner scan only considers struct/class/enum/trait. Those receiver methods therefore remain orphaned even though they are declared on a matching type in the same package; include Go type_alias nodes in the owner map so named non-struct types get the same contains edge.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff577f3fe5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }); | ||
| } | ||
| } | ||
| updated += this.linkGoReceiverMethodOwners(); |
There was a problem hiding this comment.
When callers use CodeGraph.indexFiles() to index a selected set of Go files, this new owner-linking pass never runs because it is only wired through runPostExtract() (called by indexAll/sync, while src/index.ts:392-400 returns directly from orchestrator.indexFiles). In that context, receiver methods declared in a different indexed file from their type remain without the synthesized contains edge, so the fix behaves differently depending on which public indexing API was used.
Useful? React with 👍 / 👎.
1 participant
Summary
Fixes #583.
This fixes two Go extraction/resolution gaps that left receiver methods orphaned from their owner type:
func (s *Stack[T]) Push(...), so the receiver type is recorded asStackinstead of being droppedType::Methodnodes to the matching type declared in the same package directory, even when the method is declared in a different fileThe resolver also avoids cross-directory same-name matches, so a
Widgettype in another package directory does not accidentally receive methods from the current package.Tests
npx -y -p node@22 -p npm@10 npm run test -- __tests__/extraction.test.ts -t 'Go Extraction'npx -y -p node@22 -p npm@10 npm run test -- __tests__/resolution.test.ts -t 'links Go receiver methods'npx -y -p node@22 -p npm@10 npm run test -- __tests__/extraction.test.ts __tests__/resolution.test.tsnpx -y -p node@22 -p npm@10 npm run buildnpx -y -p node@22 -p npm@10 npx vitest run --maxWorkers=1 --minWorkers=1git diff --checkNote: one initial fully parallel
npm testrun hit a timeout in the existing shared-daemon test. The same daemon test passed when rerun directly, and the full suite passed when run serially with Vitest worker limits.