Import static value member resolution

[KurodaKayn]

Feature Description

• Add NewStaticMember / TyStaticMember as the unified static member API for both static methods and static value members.
• Support resolving registered static const/var members through Typ(T).MemberVal(...) and assignable static vars through MemberRef(...).
• Register imported XGos_Type_name package-level symbols as static members on the corresponding named type.
• Treat static members and ordinary methods as one member namespace, with explicit conflict errors instead of silent types.Named.AddMethod drops.

Implementation Approach

• Upgrade the previous static-method extension path to store a types.Object, so function objects continue to behave as static methods while const/var objects resolve as static fields.
• Resolve static value members before falling back to normal type-method lookup for TypeType receivers.
• Preserve instance selector behavior by only resolving static value members from type selectors.

Testing

• go test -run 'Test(StaticMethod|ImportedStaticMember|StaticMember|StaticMemberInstantiatedGenericType|ErrStaticMember|ErrStaticMemberConflict)$' -count=1
• go test -run TestStaticMemberLoadsDelayedNamedType -count=1
• go test ./...
• git diff --check

Related

• Closes support static value members for named types #637

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.69%. Comparing base (535011f) to head (4bc9d30).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #639      +/-   ##
==========================================
+ Coverage   93.68%   93.69%   +0.01%     
==========================================
  Files          29       29              
  Lines        7221     7235      +14     
==========================================
+ Hits         6765     6779      +14     
  Misses        388      388              
  Partials       68       68              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gemini-code-assist]

Code Review

This pull request introduces conflict detection and validation for static members. Specifically, it updates NewStaticMember to check for conflicts with existing methods or static members and panic accordingly, and updates NewFuncWith to prevent adding methods that conflict with existing static members. It also adds corresponding tests for these conflict scenarios. The reviewer's feedback suggests adding defensive nil checks for typ and obj in NewStaticMember to prevent nil pointer dereferences, and removing trailing newlines from log.Panicf format strings. Additionally, the reviewer suggests updating the test assertions in TestErrStaticMemberConflict to match the updated panic messages without trailing newlines.

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: Import static value member resolution

Focused, well-tested change. The allowAccess(method.Pkg(), method.Name()) → allowAccess(obj.Pkg(), obj.Name()) switch in codebuild.go is a genuine correctness fix: the synthetic wrapper method carries the lowercase member name (e.g. name), so access control was previously evaluated against a name that always looks unexported; using the underlying object (e.g. XGos_Game_name) is the right visibility gate. TestImportedStaticMember confirms cross-package access now works. Turning silent duplicate/conflict registration into explicit fail-fast panics is also appropriate for a codegen library, and the conflict permutations are thoroughly covered.

One nit worth addressing:

• func_ext.go:263 — stale/incomplete doc comment. The NewStaticMember doc still says "other objects resolve as static fields", but this PR standardizes the user-facing term on "static value member" everywhere else (staticMemberKind, the panic messages, the NewFuncWith error at func.go:222, and the tests). Recommend aligning the wording (e.g. "…other objects resolve as static value members."). It would also help to document that this exported function now panics on a conflicting or duplicate registration, since that is a new caller-facing behavior.

Non-blocking observations (no change required):

• The conflict check added to NewFuncWith (func.go:221) adds an extra O(M) method scan per method declaration on top of an already O(M²) registration loop. Negligible for normal method counts; only matters for pathological types.
• NewStaticMember reports conflicts via log.Panicf while the parallel check in NewFuncWith returns a structured CodeError. Consistent with existing style, just noting the asymmetry.

No correctness, security, or regression defects found.

View job run