fix(go): resolve unexported receivers and nested modules within the right package (#2323, #2322)

[colbymchenry]

Summary

Two Go resolution gaps, fixed together because they turned out to be one problem: knowing which package a Go name belongs to.

• Issue Go: calls through a struct field are not resolved when the receiver type is unexported #2323 (reported by @GoDiao): calls through a method receiver of an unexported type (func (s *server) Create() { s.service.AddItem() }, the usual gRPC/HTTP handler shape) had no edge, because only a PascalCase typed parameter gave a receiver its type.
• Issue Go: cross-package calls are not resolved when go.mod is not at the project root #2322 (reported by @GoDiao): only the project-root go.mod was read, so a module in a subdirectory (svc/go.mod, a server/ backend next to a web/ frontend) or beside other modules (etcd: root go.etcd.io/etcd/v3 plus server/go.mod, client/v3/go.mod, api/go.mod…) treated every import of itself as third-party.

Why one PR: each fix alone sends calls to the wrong package, and the machinery that prevents that is shared:

• Typing unexported receivers alone (the fix(go): resolve field-chain calls on unexported method receivers #2325 pattern on main) sent 1,042 of harbor's 1,998 new calls to another package's same-named type, because the method lookup only preferred the caller's file: 653 a.SendError() calls in harbor's handlers went to common/api's BaseAPI instead of the handler package's own embedded BaseAPI, and d.dao.Create() in every daoTestSuite went to the first indexed DAO::Create.
• Reading nested modules alone (fix(go): resolve calls inside a Go module whose go.mod is below the project root (#2322) #2324 on main) makes those modules' package-qualified field types and type references resolvable by name: on harbor that added 47 self-loops (m.delegator.Count() in a caching wrapper resolving to the wrapper itself instead of artifact.Manager), and on etcd about 180 type references landing on same-named methods (testutil.TB → LazyCluster::TB, mvcc.KV → KVGetter::KV).

Both need "which directory declares this type", which needs the module map from #2322 for qualified names. Splitting would either duplicate that logic in both PRs or ship one of them with known wrong edges.

Cause

1. localReceiverTypePatterns (Go) only accepted PascalCase types for parameters and receivers, so s in func (s *server) had no type and matchGoFieldChainCall / the typed method path dropped the call (Go: calls through a struct field are not resolved when the receiver type is unexported #2323).
2. resolveMethodOnType and matchGoFieldChainCall look types and methods up by name across the whole project, breaking ties by call-site file. Go type names are only unique per package (directory), so server, DAO, Manager, Controller collide constantly; the name-based supertype walk mixed every same-named type's embeddings.
3. loadGoModule read only <root>/go.mod; getGoModule() was the single source for "is this import in the project" and "which directory is it" (Go: cross-package calls are not resolved when go.mod is not at the project root #2322).
4. A name written through a package (job.OPCommand, storage.Querier, pb.RangeRequest) is indexed bare; only external qualifiers were checked, so an in-project qualifier didn't stop the name matcher from picking a same-named symbol in another package (often a method, or the caller itself).

Fix

• Receivers and parameters of unexported types (Go: calls through a struct field are not resolved when the receiver type is unexported #2323). One Go pattern accepts a lowercase type only where a parameter list puts it — after ( / , / line start and before , / ) / line end — which covers func (s *server), func (c *cache[T]), func f(h *handler) and var ( … ) block lines, while a lowercase ident type pair elsewhere still isn't read as a declaration. This is @GoDiao's anchored-receiver approach from fix(go): resolve field-chain calls on unexported method receivers #2325, widened to parameters with the validation below.
• Package-scoped method resolution. The receiver inference now also reports the type as written (server vs store.Manager). For Go, resolveMethodOnType takes the declaring package's directory: the caller's package for a bare name, the imported package's directory for a qualified one. Only that package's Type::Method counts; a method the type lacks is looked up on the types its declaration embeds (read from the declaration, so type EphemeralKV struct{ RemoteKV }, *cached.BaseManager and interface embedding like KV { ReadView; WriteView } all work), never on another package's same-named type. When the package declares no such type (dot import, unindexed file) resolution falls back to the old name-based behaviour.
• Field chains. matchGoFieldChainCall looks for the base struct in its declaring package first and resolves the field's type in the struct's own package (bare) or the imported package (qualified).
• Nested and sibling modules (Go: cross-package calls are not resolved when go.mod is not at the project root #2322). @danusha2345's discovery from fix(go): resolve calls inside a Go module whose go.mod is below the project root (#2322) #2324: the resolver reads the nearest go.mod at or above every directory with an indexed .go file (memoized per directory, no disk walk, never above the project root; ignored and vendored trees add nothing) and maps an import path to the module with the longest matching module path, with the importing file's own module breaking a tie between two modules declaring the same path. A module under testdata/ or a _/. directory only serves its own files (the go tool ignores those directories; mattermost has a stub module there). go.work needs no separate reading: every module it lists inside the project owns indexed Go files and is found this way, and modules outside the project aren't indexed. The context API is now getGoPackageDir(importPath, fromFile?), used by isExternalImport, the cross-package call resolver, the external-qualifier guard and the field-chain matcher.
• Names written through a package. A bare reference whose source spells a package qualifier now resolves through the import to the exported symbol in that package's directory (same lookup as pkg.Func() calls), and a name-matched candidate outside the qualifier's package is rejected. A call or method value landing on a method is exempt (a package holds no methods, so that qualifier is a variable shadowing the import — prometheus's labels := &maxHeap{}; labels.get()).
• No EXTRACTION_VERSION bump: resolution only (the fix(go): resolve calls inside a Go module whose go.mod is below the project root (#2322) #2324 bump is dropped). No kernel change.

Verification

• New __tests__/go-unexported-receiver.test.ts (3 tests) and __tests__/go-nested-module.test.ts (11 tests, adapted from fix(go): resolve calls inside a Go module whose go.mod is below the project root (#2322) #2324's file plus etcd's root-plus-sibling layout, qualified type references, a caching wrapper and a testdata module). With src/ reverted to main (CODEGRAPH_KERNEL=0): 12 of 14 fail; the two controls (an import that only shares a prefix with a module path stays unresolved; a root go.mod resolves as before) pass. With the fix: 14/14 pass.
• The contributor PRs alone, against the same tests: fix(go): resolve field-chain calls on unexported method receivers #2325 passes the issue's case but sends s.Close(), s.SendError() and s.store.Put() to the other package's same-named server, BaseAPI and store; fix(go): resolve calls inside a Go module whose go.mod is below the project root (#2322) #2324 passes its own cases but links job.OPCommand to the method returning it, m.delegator.Count() to the wrapper itself, and lets a testdata module answer for the real one.
• npx tsc --noEmit clean; npm run build OK.
• The issues' own repros on the built CLI: server receiver → callers AddItem 0 → 1; svc/go.mod → callers New 0 → 1 and callers CreateItem 0 → 1; the root-go.mod and Server variants unchanged (1 / 1).
• With the native kernel loaded (built from this tree, CODEGRAPH_KERNEL_PATH): the Go tests pass, and the etcd and harbor graphs below are byte-identical to the wasm-path ones in both arms.
• Full suite (Windows, box at 100% CPU from other sessions): 5,669 passed, 53 failed in 25 files, every one Test timed out in 5000ms (plus the EBUSY cleanup that follows a timeout), no assertion failure. Rerun alone, 18 of those files passed at once; the other 7 (git-index-currency, laravel-route-paths, mcp-stale-refusal, mcp-status-freshness, mcp-unindexed, orphaned-refs-sweep, worktree-detection) timed out once more, then passed on the next run, as they do on main. After rebasing onto main (1b56cb1): tsc clean, build OK, the Go tests pass and etcd's graph is unchanged.

Validation (before = main 26e8488, whole-repo shallow clones, Go→Go edges keyed by source/target qualified name + file + line + column)

Repo (commit)	Layout	Go→Go edges	Go→Go calls	Added	Removed (re-resolved / dropped)
etcd-io/etcd (6bb7e5e)	root module + 14 sibling and nested modules (go.work)	52,530 → 66,284	18,074 → 25,265	+13,827	73 (60 / 13)
goharbor/harbor (721c6d4)	only src/go.mod	62,423 → 77,615	16,308 → 25,236	+15,819	627 (615 / 12)
prometheus/prometheus (770ca8f)	root module (+ small tool modules)	90,970 → 92,399	40,050 → 41,493	+2,249	820 (783 / 37)

No non-Go edge changed. New self-loops (etcd 5, harbor 2, prometheus 8) are all real recursion (c.Copy(...) inside client.Copy, x.left.height(...), retrying i.Next()).

Per fix, measured by switching one part off in the built branch (Go→Go edges added / removed by that part):

Part	etcd	harbor	prometheus
Unexported receivers and parameters (#2323)	+1,319 / −18	+3,568 / −176	+1,347 / −12
Nested and sibling modules (#2322)	+12,973 / −17	+13,355 / −93	0 / 0 (no cross-module imports)
Package scoping and names through a package (shared)	—	—	+902 / −808, 778 of the 808 re-resolved to the right package (prometheus is the one repo where neither part above adds much, so this row is that part alone)

The #2323 removals are name guesses (instance-method@0.65) now typed, plus field reads that used to pass as method values. For comparison, #2325 alone measured +1,131 on prometheus and +1,999 on harbor here, but 1,042 of harbor's were in the wrong package.

Added edges come from the typed path (0.9 receivers, 0.85 field chains) and from import resolution (0.9: pkg.Func() calls, pkg.Type{} literals and type references in sibling/nested modules). Spot-checked against the source, all correct (40+ across the three repos), e.g.:

• etcd ap.authClient.RoleDelete() → api/etcdserverpb AuthClient::RoleDelete (field authClient pb.AuthClient, a sibling module); cr.dial(t) in func (cr *streamReader) run() → streamReader::dial; s.cls.MemberUpdate() through the one-line type cls2clc struct{ cls pb.ClusterServer }; betesting.NewTmpBackend(...), clientv3.NewKVFromKVClient(...); backend.Backend / testutil.Action type references.
• harbor api.SendError(ctx, err) in every handler → the handler package's own embedded BaseAPI::SendError; m.delegator.NonEmptyRepos(ctx) → repository.Manager; d.artDAO.Create(...) → pkg/artifact/dao DAO::Create; suite.cache.Delete(...) → lib/cache Cache::Delete; a.client.Do(r) in func getJwtToken(a *adapter, …).
• prometheus c.chunk.Bytes() through a named result (c *memChunk, …); q.stats.GetSpanTimer(...) in func (ng *Engine) exec(ctx, q *query); s.fh.Copy(); wctx.kv.Put(...); index.Postings / storage.Querier / promql.QueryEngine result types.

Removed edges (1,520): 1,458 are the same call site or reference now resolved to the right package's symbol; sampled ones were all wrong before: harbor's handlers calling common/api's BaseAPI::SendError, suite.dao.Count() landing on pkg/accessory/dao, model_tag.Tag{ on a method ImageRepository::Tag; prometheus's tsdb.Options on discovery/refresh's Options, parser.Parser on textparse's, index.Postings result types on the method declaring them, h.bytesPool.Get() on chunkenc's Pool instead of zeropool's; etcd's pb.LeaseKeepAliveResponse on the client's own type, cli.Get(...) on kubernetes.Client instead of the embedded clientv3.KV. The 62 dropped were wrong too: field reads taken for method values (s.walDir, r.addr, m.ID, m.t, s.F all used to link to unrelated functions or methods named like the field), compression.Type where the real target is a type Type = string alias that isn't indexed (it used to link to tsdb/compression's different Type, or to a method fSample::Type), and two calls to a method xds's SDConfig doesn't have (they used to land on aws.SDConfig).

Indexing time and CPU are unchanged (harbor, process CPU incl. workers: 69.6 s / 68.7 s before vs 68.6 s / 69.4 s after; interleaved wall-clock runs within noise on all three).

Credit

@GoDiao reported both issues with precise causes and measurements, and wrote #2325 (the anchored receiver pattern adopted here, widened to parameters). @danusha2345 wrote #2324, whose module discovery (loadGoModule(moduleDir), nearest-go.mod memo, longest-prefix lookup with the own-module tie-break) and test layout are adopted here.

Related open PRs that overlap: #1954 (Go receiver typing incl. unexported/qualified params, by @danusha2345) and #1521 (Go multi-module layouts, by @ericquan8).

🤖 Generated with Claude Code