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.

[gopherbot]

Change https://go.dev/cl/434095 mentions this issue: cmd/go: show error when mod name conflict with std lib path

[mvdan]

@bcmills does the fix here also address #26227 or #34068? They all seem very similar.

[bcmills]

#34068 is in GOPATH mode, so the fix here doesn't help (this issue was for module mode).

I suspect that #26227 also still affects GOPATH mode as well, although I'm less sure about that one.

[nmiyake]

@bcmills wanted to flag that the code that merged to fix this issue (https://go.dev/cl/434095) introduced what I believe are regressions in behavior for vendor mode in Go 1.20:

#58417: cmd/go: "list -json" prints non-JSON output if vendor directory is present (Go 1.20 regression)
#58418: cmd/go: "list -json" does not populate "Dir" field for module in vendor directory (Go 1.20 regression)

I'm going to investigate further to try to understand what's going on, but as this issue doesn't mention vendoring, it seems likely that the change in behavior was an unintentional side effect of the fix for this issue.

It seems to me that, in the workflows I posted in my issue, the behavior before this change was merged was more correct, but if you could provide any clarity around that it would be much appreciated (I have tooling and workflows that depended on the previous behavior and it would be helpful to know if the new behavior is a bug where I can wait for a fix, or if the updated information/behavior is intentional and I need to figure out a different workaround).