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

[gopherbot]

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]

Comment 1:

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

[bradfitz]

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]

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]

Comment 4:

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

[bradfitz]

Comment 5:

Status changed to Accepted.

[ceh]

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

[akavel]

Related:

• x/tools/cmd/goimports: prioritize closer package #17557
• x/tools/cmd/goimports: prefer golang.org/x/net/context #15471

[gunsluo]

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.