Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: 'go mod init' should report an error if module path is in standard library #44896

Open
89z opened this issue Mar 9, 2021 · 6 comments
Open
Labels
Milestone

Comments

@89z
Copy link

@89z 89z commented Mar 9, 2021

If I have a file a_test.go:

package main
import "testing"

func TestAbs(t *testing.T) {
   t.Error()
}

This test works as expected:

PS C:\> go mod init example
PS C:\> go test
--- FAIL: TestAbs (0.00s)

However if I happen to use a builtin name, I get unexpected result:

PS C:\> go mod init log
PS C:\> go test
PASS
ok      log     0.030s

My Go:

go version go1.16 windows/amd64
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 9, 2021

Closely related: #35270 and #39285

I think the difference here is that go mod init should fail if the module path is a package (or a prefix of a package) in the standard library.

@jayconrod jayconrod added the NeedsFix label Mar 9, 2021
@jayconrod jayconrod added this to the Backlog milestone Mar 9, 2021
@jayconrod jayconrod changed the title Testing produces unexpected results if name matches standard library cmd/go: 'go mod init' should report an error if module path is in standard library Mar 9, 2021
@89z
Copy link
Author

@89z 89z commented Mar 9, 2021

@jayconrod I agree, as even though init currently succeeds, if you try to import it would just import the standard package rather than the local package.

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 9, 2021

Yeah, that ought to be an error as well (covered by #39285 I think).

Reporting an error from go mod init won't completely prevent this (go.mod could be written by hand), but it would be a good place to catch this early.

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 10, 2021

I'm not entirely convinced that go mod init should reject these. I could imagine someone using a module of this form to prototype an addition they're proposing for the standard library, or to polyfill a package added in a subsequent Go release.

@89z
Copy link
Author

@89z 89z commented Mar 10, 2021

Ok fine, but a warning at least? I could see some people going crazy because they cant figure out what they are doing wrong.

@bcmills
Copy link
Member

@bcmills bcmills commented Mar 10, 2021

#39285 would have been sufficient to diagnose the problem in the original report the first time the package was loaded (say, by go build or go test)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants