cmd/go: diagnose platform-specific identifiers when building for other platforms

[virtuald]

What version of Go are you using (go version)?

go version go1.10.3 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

main.go:

package main

func main() {
    foo()
}

foo_windows.go:

package main

import "fmt"

func foo() {
    fmt.Println("Windows")
}

Execute this command to get the error below:

$ GOOS=darwin go build

What did you expect to see?

./main.go:4:2: undefined for darwin_amd64: foo (defined for windows)

What did you see instead?

./main.go:4:2: undefined: foo

Context

When a colleague that had not used golang previously tried to compile some linux-specific project on OSX, they got the 'undefined' error above and assumed the project was simply broken, not that it was platform-specific. If the golang compiler gave this user a better error message, they most likely would have figured out their issue quicker.

It seems to me that when the compiler runs into an undefined function/constant/whatever, it would be really useful if it could look at the other platform-specific files in that directory and see if they are defined there. If so, it could emit a better error message noting that the function isn't defined for the particular platform that you're compiling for, but that it is defined for other platforms (and mention which ones).

Thinking about my imagined solution, when encountering this type of error the compiler could probably 'quickly' scan the AST of other platforms and see if the thing was defined there? In particular, since this would only be done on error, that wouldn't affect compile performance in general?

Thanks for your consideration.

[FMNSSun]

Would this scale to build tags as well?

[andybons]

@bcmills @rsc

[rsc]

This is a lot of work for seemingly very little benefit. The compiler would otherwise not even know those other files existed (it does not today). I'm not at all convinced the complexity-to-reward ratio is right for this. It seems like godoc.org would be a good place for that information.

[rajender]

While building one of our projects on windows I got following error. It would have saved me some time if error message said this is caused due to conditional compilation.

build github.com/google/gopacket/afpacket: cannot load github.com/google/gopacket/afpacket: no Go source files