[zhouguangyuan0718]

TestWasmGCSegmentBoundariesAndSweep generates both a constant and a variable named segmentedHeap, so its generated Go package fails to compile on all four platforms in the main Go workflow. Remove the duplicate constant and retain the mutable variable used to test both segmented and single-arena heap modes. All assertions remain in place; production GC code is unchanged.

The variable arrived in #2738. The duplicate constant entered main with #2742 (0831561c4d0fb7b606b8fd8545ca3e1f9b8754c9), before #2799 and #2802; neither SIMD PR changes this fixture. This isolates the existing prerequisite repair from #2819 so main can be repaired independently.

Validation on Darwin/arm64, using go test ./internal/build -run '^TestWasmGCSegmentBoundariesAndSweep$' -count=1:

• Parent of debug: inspect parked Wasm goroutine source stacks #2742 (5db83dc26): passed.
• Unmodified main (45bdf2db295a4b348a6a67d57104088acfbb7d18): reproduced the duplicate declaration and assignment-to-constant failures.
• Main plus this one-line repair (6fa1b3f413253fbd0d9dead40f01e44f10a477af): passed.
• git diff --check: passed.

Hosted CI is pending.

[fennoai]

No issues found.

Summary

This one-line change removes a redundant const segmentedHeap = true from the embedded Go source string (gcSegmentWorkloadSource) in internal/build/wasm_gc_segments_test.go. The fixture already declares var segmentedHeap = true, so the two together produced a segmentedHeap redeclared in this block compile error — and the const additionally conflicted with the reassignments in resetHeap() (segmentedHeap = true) and TestSingleArenaLookup (segmentedHeap = false), which require a mutable var. Removing the const is the correct, minimal fix.

Verification

• Reproduced the pre-fix failure: const segmentedHeap + var segmentedHeap triggers redeclared in this block (plus assign-to-constant on the reassignments).
• Confirmed the post-fix embedded source has no remaining segmentedHeap declaration conflict.
• Matches the PR description: all assertions retained, production GC code (gc_segment_default.go / gc_segment_wasi_threads.go build-tagged const) unchanged.
• Note: the full internal/build package could not be compiled in this sandbox (missing LLVM C headers), so the end-to-end go test run was not executed here; the fix was validated against the generation/type-check path in isolation.

Reviews run: code-quality, performance, security, documentation — all returned no issues. The exec.Command("go", "test", ...) path consumes only repo-controlled, non-tainted source, so no trust-boundary concern is introduced.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!