You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Three mysterious problems here (running in GOPATH mode):
$ go get -u golang.org/x/tools/cmd/goimports
$ echo 'package p; var _ = f.hash' | goimports
package p
import f "golang.org/x/exp/winfsnotify"
var _ = f.hash
$
goimports should not be trying to find an import for f.hash at all.
No import could possibly provide a lower-case name.
goimports should not be wasting time scanning packages at all.
Even if goimports were to look for a package,
why on earth did it decide to import golang.org/x/exp/winfsnotify to f?
(That package is package winfsnotify.)
Even if goimports were to look for a package and rename it to f,
why did it pick golang.org/x/exp/winfsnotify? That package does not
contain the string hashanywhere in its sources.
Like I said, mysterious (and really very annoying).
Pretty funny bug, I couldn't quite believe it so I had to look. I think this is partly new in my rewritten code and partly old.
The example hits two corner cases in the goimports logic. First, the code that collects missing references knows that lower-case identifiers can't be exported by a package, so it doesn't add them as things to look for -- but it does that after it has registered that it's looking for a package named f. Now it's looking for f, and it doesn't have to export anything.
So then it goes looking for 'f'. It finds a bunch of directories with the letter f in their name, of course, and then tries to load their exports. As it does that it tries to check the package statement of each file, and if it finds one that doesn't match, rejects the package as mismatched. But winfsnotify is for Windows, and all of its files are build tagged as such. So it never finds a package statement to check. Normally that wouldn't matter since it also didn't find anything exported. Here, though, it's good enough.
Three mysterious problems here (running in GOPATH mode):
goimports should not be trying to find an import for
f.hash
at all.No import could possibly provide a lower-case name.
goimports should not be wasting time scanning packages at all.
Even if goimports were to look for a package,
why on earth did it decide to import golang.org/x/exp/winfsnotify to f?
(That package is
package winfsnotify
.)Even if goimports were to look for a package and rename it to f,
why did it pick golang.org/x/exp/winfsnotify? That package does not
contain the string
hash
anywhere in its sources.Like I said, mysterious (and really very annoying).
/cc @heschik @ianthehat @bradfitz
The text was updated successfully, but these errors were encountered: