ci: test LLGo across Go 1.20 through 1.26

[cpunion]

Summary

• build llgo and repository tooling only with the Go 1.26 patch pinned in .go-version
• test test/ with exact Go 1.20–1.26 toolchains, matching temporary module versions, and GOTOOLCHAIN=local
• run full Go 1.25/1.26 coverage on Linux and macOS; run representative Go 1.20–1.24 sets on alternating platforms
• make release-tagged std tests and symbol coverage follow the actual target toolchain
• add reusable single-version and local integration scripts for test, runtime, wasm, hello, and GOROOT jobs
• route the legacy runtime/trace.runtime_readTrace entry to LLGo's existing trace reader so Go 1.20–1.25 StopTrace completes

The native runtime remains compatible with Go 1.20. The wasm runtime starts at Go 1.24 because it uses structs.HostLayout. This change does not add clite fallbacks or source patches.

CI time

Versions run in separate jobs. Recent full jobs take about 18–21 minutes on Ubuntu and 26 minutes on macOS; full-job limits are 40 and 45 minutes. Go 1.20–1.24 jobs cover only representative packages. The sequential all-version integration script is local-only.

Validation

• Go 1.20–1.24 representative LLGo tests and symbol checks
• Go 1.25 release-tag audit: 173/173 std packages and all exported symbols covered
• Go 1.25 full test/go (478s), and Go 1.25/1.26 native tests
• Go 1.20/1.25 runtime/trace, including the FlightRecorder stop path that previously timed out
• runtime Go 1.20/1.26 and wasm Go 1.24/1.26
• Go 1.26 hello including ESP32
• shellcheck, actionlint, YAML parsing, gofmt, and git diff --check

This supersedes the earlier minimal CI recovery; main already contains the separate Go 1.25 cgroup bridge from #2356.

[fennoai]

Review: ci: build llgo only with Go 1.26

This is a clean, low-risk CI-only change. It drops the failing Go 1.25 full-build and per-package test matrix rows, keeping only the pinned Go 1.26.5 primary lane — consistent with the stated minimal recovery after #2346. Sharding logic remains correct (Ubuntu 2 shards / macOS 1 shard, disjoint modulo partition), and the security posture is unchanged (pull_request trigger, author-controlled matrix values only). No blocking issues.

The findings below are maintainability/accuracy notes, not correctness bugs.

Inline

• Two rewritten header comments (llgo + test jobs) now describe compatibility/older-source coverage that the change just removed. See inline comments.

Additional observations (no reliable inline location — pre-existing lines outside the diff)

• Dead continue-on-error guards. Both llgo (line 20) and test (line 131) still carry continue-on-error: ${{ matrix.lane == 'compatibility' }}. After this change neither job's matrix ever produces lane: compatibility (all rows are primary), so both guards are now permanently false. Consider removing them, or add a note if a compatibility lane is expected to return. (The same expression stays live in hello via its Go 1.25 row.)

• std_pkgs guard hardcodes 1.26.5 (silent coverage-loss risk). In the test job run step (line 208), the std build-mode selection is gated on "${{ matrix.go }}" == 1.26.5. Now that 1.26.5 is the only Go value in this matrix, a future Go pin bump on line 141 would silently stop this literal from matching, skipping dev/test_std_buildmodes.sh with no failure. Consider driving this off matrix.lane == 'primary' (semantic intent) or a single version source of truth. The lane: primary include keyed on the same literal (lines 145-147) shares this coupling — a pin bump there would render blank lane segments in the job name.

• Residual Go 1.25 legs. hello (line 231) and wasm-runtime (line 346) still run Go 1.25.0. This matches the PR intent of keeping demo/hello/wasm-runtime compatibility coverage while dropping the full build/test 1.25 rows — flagging only to confirm it's deliberate.

• Action pinning (pre-existing, out of scope). Actions are pinned to mutable tags (e.g. actions/checkout@v7, emscripten-core/setup-emsdk@v15) rather than commit SHAs. A supply-chain hardening opportunity, unrelated to this change.

View job run

[fennoai]

[P3] Stale comment: 'test' lane no longer provides source compatibility

This comment delegates "source compatibility" to "the runtime, demo, and test lanes below," but this PR removes the test job's compatibility row (it is now primary-only on Go 1.26.5), and there is no runtime lane in this file. The only surviving compatibility coverage is the hello job's Go 1.25 row. Consider pointing the comment at hello instead.

[fennoai]

[P3] Stale comment: 'test' job no longer tests older source versions

The second sentence ("Older source versions need a separate injected go.mod version") no longer applies to this job: the matrix is now a single go: ["1.26.5"] with only a primary lane, and nothing here injects a go.mod version. That injected-version behavior lives in the hello job's mod-version steps. Consider dropping or rewording this line to avoid misleading future readers.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

LLGo baseline benchmarks

e7e6b163a1b9 | workflow run | long-term charts

Program measurements

Platform	Workload	File size	vs base	Build	vs base	Run	vs base
Linux	cprintf	19384 B	0 B / +0.0%	339.014 ms	+100.4 ms / +42.1% (worse)	815.531 us	-7.063 us / -0.9% (better)
Linux	fmtprintf	1880808 B	+32 B / +0.001701% (worse)	2.019 s	-146.3 ms / -6.8% (better)	2.218 ms	+103.3 us / +4.9% (worse)
Linux	println	68880 B	0 B / +0.0%	236.462 ms	-18.78 ms / -7.4% (better)	1.046 ms	+53.64 us / +5.4% (worse)
macOS	cprintf	84672 B	0 B / +0.0%	427.077 ms	+34.96 ms / +8.9% (worse)	3.856 ms	+791.5 us / +25.8% (worse)
macOS	fmtprintf	1892208 B	0 B / +0.0%	4.425 s	+1.428 s / +47.6% (worse)	18.663 ms	+1.887 ms / +11.2% (worse)
macOS	println	121376 B	0 B / +0.0%	443.546 ms	-66.97 ms / -13.1% (better)	5.336 ms	+411.2 us / +8.3% (worse)

Core language and compiler benchmarks

Platform	Benchmark	ns/op	vs base
Linux	BenchmarkLookupPCRandom	8.113 ns/op	+0.007 ns/op / +0.1% (worse)
Linux	BenchmarkMergeCompilerFlags	100.200 ns/op	+0.2 ns/op / +0.2% (worse)
Linux	BenchmarkMergeLinkerFlags	64.280 ns/op	-0.17 ns/op / -0.3% (better)
Linux	BenchmarkChannelBuffered	39.360 ns/op	-0.69 ns/op / -1.7% (better)
Linux	BenchmarkChannelHandoff	25470 ns/op	+2868 ns/op / +12.7% (worse)
Linux	BenchmarkDefer	36.340 ns/op	-1.78 ns/op / -4.7% (better)
Linux	BenchmarkDirectCall	0.248 ns/op	-0.0031 ns/op / -1.2% (better)
Linux	BenchmarkGlobalRead	0.354 ns/op	+0.0037 ns/op / +1.1% (worse)
Linux	BenchmarkGlobalWrite	6.981 ns/op	+0.003 ns/op / +0.04299% (worse)
Linux	BenchmarkGoroutine	35630 ns/op	-194 ns/op / -0.5% (better)
Linux	BenchmarkInterfaceCall	3.849 ns/op	-0.218 ns/op / -5.4% (better)
Linux	BenchmarkRuntimeGetG	0.740 ns/op	+0.0063 ns/op / +0.9% (worse)
macOS	BenchmarkLookupPCRandom	16.810 ns/op	+4.44 ns/op / +35.9% (worse)
macOS	BenchmarkMergeCompilerFlags	180.700 ns/op	+33.9 ns/op / +23.1% (worse)
macOS	BenchmarkMergeLinkerFlags	153.100 ns/op	+73.49 ns/op / +92.3% (worse)
macOS	BenchmarkChannelBuffered	24.580 ns/op	-5.69 ns/op / -18.8% (better)
macOS	BenchmarkChannelHandoff	7490 ns/op	-2833 ns/op / -27.4% (better)
macOS	BenchmarkDefer	34.480 ns/op	-8.22 ns/op / -19.3% (better)
macOS	BenchmarkDirectCall	1.044 ns/op	-0.413 ns/op / -28.3% (better)
macOS	BenchmarkGlobalRead	1.541 ns/op	+0.324 ns/op / +26.6% (worse)
macOS	BenchmarkGlobalWrite	1.353 ns/op	+0.143 ns/op / +11.8% (worse)
macOS	BenchmarkGoroutine	29085 ns/op	-7797 ns/op / -21.1% (better)
macOS	BenchmarkInterfaceCall	5.860 ns/op	-0.86 ns/op / -12.8% (better)
macOS	BenchmarkRuntimeGetG	2.599 ns/op	+0.096 ns/op / +3.8% (worse)

Compared with 275a648d7d68 measured in the same runner job.