cmd/go: ambiguous import path not detected when the colliding path is in the standard library

[gertcuykens]

Suggest in Go 1.14 we go one step further when GO111MODULE="on", outside and inside! GOPATH, module path must be specified to prevent shenanigans.

When trying to create a module crypto outside gopath you get

% go mod init
go: cannot determine module path for source directory /Users/gert/crypto (outside GOPATH, module path must be specified)

Perfect, but if you do that inside gopath

(force GO111MODULE="on")
% mkdir $GOPATH/src/crypto
% cd $GOPATH/src/crypto
% echo "package crypto" > c_test.go
% go mod init
% cat go.mod
module crypto
go 1.14
% go test -v
=== RUN   TestRC4OutOfBoundsWrite
--- PASS: TestRC4OutOfBoundsWrite (0.00s)
=== RUN   TestCTROutOfBoundsWrite
--- PASS: TestCTROutOfBoundsWrite (0.00s)
=== RUN   TestOFBOutOfBoundsWrite
--- PASS: TestOFBOutOfBoundsWrite (0.00s)
=== RUN   TestCFBEncryptOutOfBoundsWrite
--- PASS: TestCFBEncryptOutOfBoundsWrite (0.00s)
=== RUN   TestCFBDecryptOutOfBoundsWrite
--- PASS: TestCFBDecryptOutOfBoundsWrite (0.00s)
PASS
ok      crypto  0.049s

Not only is it allowed, you even launch the wrong test files from GOROOT

I understand this is done for backward compatible sake, but GOPATH must die and end up somewhere as a dot folder hidden only used for cach.

Furthermore I suggest to change error message

go: cannot determine module path for source directory /Users/gert/crypto (outside GOPATH, module path must be specified)

to

go: cannot determine module path for source directory /Users/gert/crypto (module path must be specified)

to stop promoting people to use GOPATH

(related to: #35070)

[bcmills]

This has ~nothing to do with specifying module paths: it would be conceptually ok (if somewhat fragile) to create a module crypto provided that it does not define any packages that are also defined in GOPATH/src.

The problem here is that the existing ambiguous import error is not detecting the collision between the user's module and the standard library. That should be a much easier (and less invasive) fix.

CC @jayconrod

[bcmills]

See also #26227.

[ianlancetaylor]

@bcmills Is this likely to happen for 1.18? Thanks.

[bcmills]

I'm not sure. It should be a fairly easy fix, but it doesn't need to hold up the release; moving to 1.19 for now, but I may move it back if the fix turns out to be small enough to go in during the freeze.