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: eliminates imports whose package name doesn't match last path component #21143
Comments
Seems like the imports which have "-" get deleted. Naming them solves the problem. Is this intended behavior? for ex. "github.com/emicklei/go-restful" gets removed while "restful github.com/emicklei/go-restful" does not. |
Thanks for the bug report. (Btw, please update to Go 1.8.3, and try out the 1.9 betas!) goimports assumes that the package's name ( That said, it seems to me: (1) if you already have the import present in your file, goimports should always check that import path when looking for matches |
This is #17546, which was recently closed. Note that in that case he was using I'm not too convinced it's worth complicating |
@kenan435, can you (or anybody else here) prepare a reproducible example with versions? Which git version of goimports? |
So it's the current (2017-07-24) tip of To reproduce on
The dashed import was removed but that path is required because it provides the |
@ALTree, thanks! |
I'm on the fence about this. In any case, I do think goimports should check existing imports before deleting them (my option 1 above). So let's leave this bug open for that. |
Definitely seems like there's a bug here. I haven't investigated, though, and won't have time to (https://groups.google.com/forum/#!topic/golang-dev/5QdnNBf1v68). |
@ALTree I tried to reproduce with those versions, but couldn't. Specifically, I did:
This shows no diffs, however. I also tried to build a minimum working example (on the hypothesis above, that this is happening if a package contains a dash and the package name deviates from the last component) by having this (and a couple of variations on it):
My go installation itself is currently on tip, but I also couldn't reproduce with go 1.8.1. Did you use a clean GOPATH? (I found this issue looking for something productive to contribute for the first time; so I might be missing something completely obvious and/or stupid :) ) |
@Merovius Thanks for double checking. I still can reproduce this but now I notice that in the instructions I gave above I didn't
I don't recall if this use case is supported by goimports. |
@ALTree Yes, I can reproduce that now (with the additional step of checking out anything before c267afd3ecb on the kubernetes tree, of course). It shows a diff if the repo is checked out outside of $GOPATH and no diff, if it's inside $GOPATH. I'm going to try and look whether I can find and fix this over the next couple of days, supported or not. Unless someone tells me to stop :) |
Minimal repro:
Meaning this is #14566. goimports doesn't associate the "c" import with package "a" by heuristic and I recommend closing this as a dupe of #14566 (I don't think I can do that myself). |
Thanks for investigating. Since it can only be reproduced when the |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.8.1 linux/amd64
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build210705530=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
What did you do?
Used goimports instead of gofmt tool to format https://github.com/kubernetes/dashboard codebase.
What did you expect to see?
Fixing imports and format code in the same style as gofmt.
What did you see instead?
Code got formated and imports nicely ordered where standard libraries are listed first and 3rd party imports second. Unfortunately in several files legit imports got removed causing errors and failed build. Naming the imports by hand fixes the problem but the behavior is unpredictable as I don't see why the specific files were affected.
The text was updated successfully, but these errors were encountered: