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

x/tools/cmd/goimports: Handle ambiguous import properly #9197

Open
gopherbot opened this issue Dec 2, 2014 · 8 comments

Comments

@gopherbot
Copy link

commented Dec 2, 2014

by cnyegle:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What does 'go version' print?
go version go1.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

Run goimports over this code http://play.golang.org/p/u_HSZ6xDLX

What happened?
goimports suggest me to import "html/template"


What should have happened instead?

goimports should suggest "text/template" as well, or add that in a comment
with FIXME: tag.

Please provide any additional information below.

goimports worked very well in the past, so when I find there's some strange escaped
character in my template.Execute result it took me a long time to figure out the reason.

text/template and html/template have same signature for most if not all functions, so
the compiler didn't complain anything.

I'd suggest when modifying/suggesting the imports, the tool put all possible candidates
in comment with FIXME: tag.
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Dec 2, 2014

Comment 1:

Labels changed: added repo-tools, release-none.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 2, 2014

Comment 2:

I can't reproduce this.
My goimports doesn't do anything to that code since it's ambiguous.
Are you sure that was the code you had?

Status changed to Invalid.

@gopherbot

This comment has been minimized.

Copy link
Author

commented Dec 2, 2014

Comment 3 by cnyegle:

Yes this is the exact code I used (admittedly the code is broken)
$ cat test.go 
package main
func main() {
        template.New
}
(.py3kvenv)ych@ych-linux1 ~ 
$ goimports -d test.go 
diff test.go gofmt/test.go
--- /tmp/gofmt702883055 2014-12-02 15:12:30.084992075 -0800
+++ /tmp/gofmt533762434 2014-12-02 15:12:30.084992075 -0800
@@ -1,5 +1,6 @@
 package main
 
+import "html/template"
 
 func main() {
        template.New
@minux

This comment has been minimized.

Copy link
Member

commented Dec 2, 2014

Comment 4:

Brad, I can reproduce it with the latest version of golang.org/x/tools/cmd/goimports.
@bradfitz

This comment has been minimized.

Copy link
Member

commented Dec 2, 2014

Comment 5:

Status changed to Accepted.

@ceh

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2015

Should the current behavior be preserved for non-stdlib packages in go env GOPATH? E.g. "If there are multiple candidate packages, the shortest one wins.": golang.org/x/tools/imports/fix.go:356

@mikioh mikioh changed the title go.tools/cmd/goimports: Handle ambiguous import properly cmd/goimports: Handle ambiguous import properly Jan 22, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title cmd/goimports: Handle ambiguous import properly x/tools/cmd/goimports: Handle ambiguous import properly Apr 14, 2015

@rsc rsc modified the milestones: Unreleased, Unplanned Apr 14, 2015

@rsc rsc removed the repo-tools label Apr 14, 2015

@akavel

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2017

Related:

@gunsluo

This comment has been minimized.

Copy link

commented Dec 23, 2018

i have the same question. i import two third-party packages (A and B). A and B use the same package C. but there is different version C in the go.mod of A and B.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.