mod: xgo 1.7.3, gid 0.3.1

[visualfc]

No description provided.

[gemini-code-assist]

Code Review

This pull request replaces the dependency github.com/timandy/routine with github.com/visualfc/gid to retrieve the goroutine ID in interp.go. Feedback on the changes highlights a compilation error due to a type mismatch, as gid.Get() returns an int64 while goroutineID() is defined to return a uint64. An explicit type cast is suggested to resolve this issue.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[fennoai]

Review: mod: xgo 1.7.3, gid 0.3.1

This is a clean dependency update. All four review dimensions (code quality, performance, security, documentation) came back without blocking issues.

What was verified:

• gid.Get() returns uint64 — the existing Gemini bot comment suggesting it returns int64 and requires a uint64(...) cast is a false positive. The type contract of goroutineID() uint64 is satisfied without any cast.
• On standard Go builds, gid.Get() is a one-line wrapper over routine.Goid(), so runtime behavior and performance are identical to before.
• timandy/routine is correctly demoted to indirect at v1.1.6 (the version gid itself requires), and the go.sum entries are consistent.
• Upgrading gogen from a pre-release (v1.23.0-pre.5) to a stable release (v1.23.3) is a healthy change.

One point to be aware of (non-blocking):
Under the llgo build tag, gid.Get() returns uint64(uintptr(pthread_self())) — a thread ID, not a goroutine ID. The three call sites in interp.go (lines 149, 549, 1177) use the result as a map key to track per-goroutine deferred calls and the main goroutine ID. If ixgo is ever compiled with llgo, the defer-frame isolation and main-goroutine detection would silently operate on thread identity rather than goroutine identity. This is likely intentional (llgo maps goroutines 1:1 to threads), but worth a brief comment if llgo support is a stated goal.