[xushiwei]

• Proposal: GoFiles — mixing hand-written and generated Go code #1100

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.25%. Comparing base (1cb3304) to head (b5682e8).

Files with missing lines	Patch %	Lines
cl/preload_go.go	91.45%	10 Missing ⚠️
cl/compile.go	75.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1101      +/-   ##
==========================================
+ Coverage   90.00%   90.25%   +0.24%     
==========================================
  Files          25       26       +1     
  Lines        3132     3272     +140     
==========================================
+ Hits         2819     2953     +134     
- Misses        313      319       +6     

Flag	Coverage Δ
llgo-tests	90.25% <92.30%> (+0.24%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fennoai]

FennoAI Review: GoFiles feature

This PR adds support for mixing hand-written Go source (GoFiles) with generated Go code during C/C++ header conversion. Clean design overall: the eager-declare / lazy-resolve split via addLoadUnit correctly handles forward and mutually-recursive type references, and the self-alias early-return in aliasType (.Color -> existing Go Color) avoids a spurious redeclaration. Build and go vet pass for cl/ and tool/.

Note: the full test suite could not be executed in this environment because the clang/llgo link step requires the llgo toolchain (undefined llgo.* / C.clang_* symbols at link time). Static analysis (go vet) passed; the findings below are from code inspection.

Key findings below. The most important is a nil-pointer panic on any unaliased import in a hand-written Go file — not covered by the single raylib2 fixture (which has no imports).

Documentation consistency (not inline — spans many files)

Several doc comments had their issue-tracker URLs changed from github.com/goplus/llcppg/issues/... to github.com/xgo-dev/llcppg/issues/... (issues 1051, 1061, 1064), and the new GoFiles comments reference xgo-dev/.../1100. But other existing comments still use goplus:

• cl/ctx.go:519, cl/ctx.go:543, cl/typedef.go:210, cl/preload.go:383, cl/preload.go:399 — all goplus/llcppg#1097
• cl/macrogroup.go:28 and cl/cltest/cltest.go:95 — goplus/llcppg/issues/1064

Note the direct contradiction on issue 1064: cl/compile.go:164 and tool/config.go:163 now point to xgo-dev/.../1064, while cl/macrogroup.go:28 and cl/cltest/cltest.go:95 point to goplus/.../1064 — same issue, two orgs. At most one is correct. If the repo is migrating goplus -> xgo-dev, the remaining goplus references are now stale; if the rename was unintended, the new comments are wrong. Flagging for a maintainer decision.

Minor (not inline)

• cl/cltest/cltest.go:39 and tool/config.go:49: the GoFiles []string field has no json:"GoFiles" tag while nearly all sibling fields do. Harmless (encoding/json case-insensitively matches the field name, so in.cfg's "GoFiles" key parses), but inconsistent — consider adding the tag for parity and explicitness.
• The GoFiles paths are resolved relative to destDir (tool/gen.go:105 -> LoadGoFiles(fset, destDir, ...)), not Dir where Files and other source lists are rooted. This surprising-but-intentional contract is undocumented in the GoFiles/LoadGoFiles doc comments — worth a line so it is not misconfigured.