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

Open
mdempsky opened this issue May 27, 2020 · 4 comments

Comments

@mdempsky
Copy link
Member

@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 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
Copy link
Member

@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:
https://play.golang.org/p/WMIbECf3o0s

@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
@deven96
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?

@bcmills
Copy link
Member

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

@bcmills
Copy link
Member

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

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
5 participants