Related Issues

• x/build: add a Windows ARM64 builder #42604 (closed)
• x/build/env/windows/arm64: windows/arm64 builders are down #57408 (closed)
• x/build: add a Windows ARM32 builder #46492 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Change https://go.dev/cl/634077 mentions this issue: _content/doc/go1.24: document broken windows/arm port

IMO, the important fact here is that windows/arm32 has been broken since Go 1.17 and nobody complained until now, almost 4 years later. Additionally, Windows 11 no longer supports arm32, not even via arm64 to arm32 emulation. From https://learn.microsoft.com/en-us/windows/arm/arm32-to-arm64:

Windows devices running on an Arm processor (for example, Snapdragon processors from Qualcomm) will no longer support AArch32 (Arm32).

Given these facts, I'm inclined to remove the windows/arm32 port altogether. This will also help making the Windows port easier to maintain, as it's one less architecture to touch when refactoring the compiler and the runtime.

Please elide broken platforms from go tool dist list.

That mechanism can act as a single source of truth for working platforms, so that dev utilities like factorio can function without requiring constantly republishing manual lists of broken ports.

https://github.com/mcandre/factorio

Could there be a Go stdlib API member, so we don't need to shell out every time?

@mcandre go tool dist list already leaves out broken ports by default. Broken ports can be listed too by passing in the -broken flag.

$ go version
go version go1.24.0 darwin/arm64
$ go tool dist list | grep windows/arm
windows/arm64
$ go tool dist list -broken | grep windows/arm
windows/arm
windows/arm64

$ GOTOOLCHAIN=go1.17.13 go tool dist list | grep windows/arm
windows/arm
windows/arm64

That was issue #56679.

There's no package in the standard library that's a good fit for this, and this information can changes only in major Go releases, so at most once every 6 month, so executing a cmd/dist shouldn't be too onerous. If you still think there's more to do, please file a separate issue for that, since this issue is about the window/arm port specifically. Thanks.