cmd/go: diagnose collisions between standard-library packages and packages provided by modules

[mdempsky]

As discussed on golang-dev@, this currently runs without warnings/errors, but doesn't do what I'd intuitively expect:

$ go mod init example.com/main
go: creating new go.mod: module example.com/main
$ go mod edit -replace go/types=./nonexist
$ echo 'package main; import _ "go/types"; func main() {}' > main.go
$ go build .

/cc @bcmills

Edit: For posterity, my "intuitively expected" behavior here is/was that the import of "go/types" should be remapped to "./nonexist", and cause a build error because it doesn't exist.

[bcmills]

If the replacement path is ./nonexist, then this is working as intended: you could use this approach to slot in experimental subpackages (perhaps named go/types/internal and go/types/generic 😁) without modifying the rest of the standard library.

The thing we should diagnose is a module (either the main module or one slotted in by a replace directive) for which the target contains at least one .go source file at the same import path as a standard-library package, which we apparently do not today:
https://play.golang.org/p/WMIbECf3o0s

[deven96]

By diagnose, what exactly do you expect @bcmills , a log that warns of collisions at the same import path?
Can I work on this as a first time contributor?

[bcmills]

By “diagnose” I mean ”emit an error for the affected packages if they are ever loaded”.

I wouldn't recommend that anyone work on this issue right now, because I'm in the middle of refactoring the module-mode loader for #36460 and the merge conflicts would probably be pretty unpleasant.

[bcmills]

This also isn't specific to replace directives, since the main module itself could have a name that is (or is a prefix of) a package path in the standard library (#42721).