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: diagnose collisions between standard-library packages and packages provided by modules #39285

mdempsky opened this issue May 27, 2020 · 6 comments
GoCommand modules NeedsFix


Copy link

@mdempsky mdempsky commented May 27, 2020

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

$ go mod init
go: creating new go.mod: module
$ 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.

@andybons andybons added GoCommand NeedsInvestigation labels May 28, 2020
@andybons andybons added this to the Unplanned milestone May 28, 2020
Copy link

@bcmills bcmills commented May 29, 2020

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:

@bcmills bcmills added the modules label Jun 1, 2020
@bcmills bcmills removed this from the Unplanned milestone Jun 1, 2020
@bcmills bcmills added this to the Backlog milestone Jun 1, 2020
@bcmills bcmills changed the title cmd/go: should warn/error about replacements of standard library packages cmd/go: diagnose collisions between standard-library packages and packages provided by modules Jun 1, 2020
@bcmills bcmills added the NeedsFix label Jun 1, 2020
@gopherbot gopherbot removed the NeedsInvestigation label Jun 1, 2020
Copy link

@deven96 deven96 commented Aug 26, 2020

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?

Copy link

@bcmills bcmills commented Aug 28, 2020

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.

Copy link

@bcmills bcmills commented Nov 19, 2020

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).

Copy link

@luojiego luojiego commented Jan 5, 2022

go mod init http is ok, but when I use go mod init sort, Something terrible happened, the VS Code Show me an error.
But it was still good a few days ago. I began to suspect that it was a problem with VS Code, and then a problem with the Go version. Until I reinstalled them all, I even tried to download GoLand to find a solution. Finally I found could‘t use sort. This feels too bad. If all the package names of the standard library cannot be used, I agree. But some work, some don't work, I think this is a bug.

Copy link

@bcmills bcmills commented Jun 15, 2022

Duplicate of #35270

@bcmills bcmills marked this as a duplicate of #35270 Jun 15, 2022
@bcmills bcmills closed this as not planned Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
GoCommand modules NeedsFix
None yet

No branches or pull requests

6 participants