cmd/go: return an error for unsupported GOOS/GOARCH pair

[bradfitz]

This bug is about cmd/go returning a useful error message when an invalid GOOS/GOARCH pair is used.

See confusion in #11908.

Related request in #12270 (if we fix this bug, we should probably fix both, using the same source of truth)

[minux]

How about we make cmd/go print "perhaps unsupported platform?" message if some core std packages (runtime, syscall and net?) have build errors? Then we don't nees to maintain a list of supported platforms. or we can detect whether there exists runtime/defs_$GOOS_$GOARCH.go file to see if the platform is supported. (I'm a little sad about the recent duplication of the list of cgo-enabled platforms in cmd/dist. I even want to suggest that we make cmd/dist generate the list for go/build)

[rakyll]

How about we make cmd/go print "perhaps unsupported platform?"

It won't help the users if the error message is uncertain, they will end up in the issue tracker or the mailing list to ask about the case.

Maintaining a single source of truth for the supported combinations are rather easy and explicit.

[minux]

I have another proposal. We store the list of supported platforms in cmd/dist, and have it generate a list of supported platforms for cmd/go and a list of cgo enabled platforms for go/build.

[rsc]

Not critical for Go 1.6.

[gopherbot]

CL https://golang.org/cl/22838 mentions this issue.

[a13xb]

Funny enough, we relied on the old behaviour.

We use go tool to build for Linux/MIPS target using gccgo (which does support MIPS), and works fine with 1.6, but now it's blocked by this check.