x/tools/cmd/goimports: fails to distinguish package from global variable

[gopherbot]

by peterbourgon:

$ go version
go version go1.2.1 darwin/amd64

$ cat a.go
package main

import (
        logpkg "log"
        "os"
)

var (
        log = logpkg.New(os.Stdout, "", 0)
)

func main() {
        b()
}

$ cat b.go
~/src/tmp/logerr cat b.go
package main

func b() {
        log.Printf("hello")
}

$ goimports -d b.go
goimports -d b.go
diff b.go gofmt/b.go
--- /var/folders/lj/1qllh78d2qqbyxkdg5jldcym0000gn/T/gofmt154060612     2014-03-04
14:56:26.000000000 +0100
+++ /var/folders/lj/1qllh78d2qqbyxkdg5jldcym0000gn/T/gofmt436718547     2014-03-04
14:56:26.000000000 +0100
@@ -1,5 +1,7 @@
 package main

+import "log"
+
 func b() {
        log.Printf("hello")
 }

goimports doesn't detect that log.Printf in b.go refers to the global variable
"log" defined in a.go, and erroneously imports the log package. Put another
way, the expected diff is nothing.

[griesemer]

Comment 1:

goimports works on a file-by-file basis like gofmt; and as such it does not and cannot
know that file a.go and b.go belong to the same package.
Put another way, this is a user error for the tool as is.
Leaving to bradfitz to decide whether to close or convert to a feature request.

Owner changed to @bradfitz.

[griesemer]

Comment 2:

Labels changed: added repo-tools.

[bradfitz]

Comment 3:

I'm not motivated to change this. Seems rare enough. goimports strives to be convenient
most of the time, but it doesn't need to be perfect.
I wouldn't argue against somebody else fixing it if it can be fixed simply, but I'm not
sure how.

Owner changed to ---.

Status changed to Thinking.

[gopherbot]

Comment 4 by peterbourgon:

> Seems rare enough.
I use this idiom in most of my servers, to aid in testing.

[rsc]

Comment 5:

Labels changed: added release-none.

[gopherbot]

Comment 6 by [email protected]:

> Seems rare enough.
I use this idiom in most of my packages as well

[bradfitz]

Comment 7:

Labels changed: added restrict-addissuecomment-commit.

[abourget]

I'm hitting the same issue here.. exactly with that log thing..

Also, not recognizing the global var massively slows down goimports, because it seems to initiate a search in all $GOPATH code (there's quite a bit in there).

[abourget]

When working with such a package, goimports actually becomes a hinderance, because it adds unwanted things that then need to be fixed manually, on each run.

I understand we want to keep goimports work on a single file.. could we annotate things, then ? (not a superb solution either.. bbbuuuttt! :)

[powerman]

Well, import _ "log" will make goimports happy.

[graffic]

I must say that this happens only some times. I have a package with multiple files. One file has the famous log variable.

For months I didn't hit this bug, but today it started to happen in one file only.

[powerman]

For months I didn't hit this bug, but today it started to happen in one file only.

Probably you have used some other fields/methods on your log variable which helps goimports to distinguish between correct and wrong log packages, but this has change and now you're using only fields/methods compatible with standard log package in this file, so this changed goimports result.

[graffic]

Probably you have used some other fields/methods on your log variable which helps goimports to distinguish between correct and wrong log packages, but this has change and now you're using only fields/methods compatible with standard log package in this file, so this changed goimports result.

Spot on.

Anyway, I solved the issue changing the variable name from log to logger.

[briantkennedy]

proposed fix https://go-review.googlesource.com/23444

[gopherbot]

CL https://golang.org/cl/23444 mentions this issue.

[gopherbot]

CL https://golang.org/cl/25140 mentions this issue.