cmd/go: should help users understand when a new GOOS or GOARCH breaks their build

[theckman]

We ran to an interesting issue today in the Go newbies channel on the Slack workspace, specifically around a user's build breaking in between Go v1.10.x and v1.11.x. I'm not sure if there's really a tenable solution here, but I thought it was worth starting a discussion with the Go authors.

This user upgraded from Go v1.10.x to Go v1.11.2 with no other changes to their code, and they were then met with build failures:

./swaguidist.go:15:38: undefined: swaggerUiBundleJs
./swaguidist.go:17:38: undefined: swaggerUiStandalonePresetJs

When the user tried to figure out what was wrong, they incorrectly asserted that because some of the files in the package were large the compiler was ignoring them. They reached out to the Slack workspace to see whether anyone was aware of such a limitation, but thankfully we happened to spot the files ending in *_js.go.

While I think it's ideal to expect everyone to read the release notes in their entirety, I don't think we'll ever get to that place. It makes me wonder if there're are any options available to us that would make these things a little more approachable and actionable (especially to newbies), versus something like a variable not defined error.

[ianlancetaylor]

Yes, this change in the handling of file names is an ongoing slow moving problem.

[cznic]

FTR: This is not about a language change breaking builds. The build system is not the language.

[jimmyfrasche]

Should the mechanism introduced in #28221 be used to ignore build constraints that were not yet reserved by the language version recorded by the module?

[ianlancetaylor]

@cznic Thanks, updated issue title.

@jimmyfrasche I worry that relying on that is likely to increase confusion rather than decrease it.

[bcmills]

As confusing as the language-version switch may be, I suspect it's the least-confusing of the options: at the very least, it preserves the property that programs that were correctly-structured in one release remain correctly-structured over time.

[matloob]

I don't think we've made any recent additions to goos and goarch suffixes that are used to select files for the build, but if we do, we should tie them to the version of the go.mod file. That should probably be a different issue though. Closing this one.