-
Notifications
You must be signed in to change notification settings - Fork 18k
x/tools/cmd/goimports: interspersed comments can be associated with the wrong import #28200
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
Comments
We also ran into this issue. Searching arround we found that this commit to the tools repository introduces this bug: Checking out/building any prior commit fixes the problem. |
We hit this too - seems to be a regression introduced in the above commit, since it's clearly not doing the right thing. |
/cc @bradfitz |
@saheienko, can you look into this bug? It seems to have been caused by your previous change. |
(And if it's easier for you, we can just revert your change for now until you have a fixed version of it. But if you can easily fix quickly, we can roll forward instead of back.) |
@bradfitz yes, I'll try, but not sure it's related. Looks like goimports grabs a comment that follows the import path (as in the linked issues). #26921 similar to this, I've even added a test case for it: golang/tools@12a7c31#diff-2ce00388d8d7ca66d8abc5ae7c3954b5R1127 |
As @lopezator said, the problem is exactly in that concrete commit 12a7c31:
|
Hi @lopezator, let's use another instances. Build goimports:
In both cases it fails to place the comment.
Valid import comments:
More groups:
You can see, the mentioned commit(#20818) just ensures grouping of imports(std, third-party, appegine, local) and it's not the root problem for this issue. As I understand, for the ast parser a valid import comment shoud follow the spec on the same line. Other comments goimports tries to assign to some import spec. |
Hello @saheienko I went over your examples and your are right, both of them fail given that input. However, in our specific usecases golang/tools@87312bc doesn't break, and golang/tools@12a7c31 indeed does. Supposing we have both binaries built and in place as you explain in #28200 (comment) Lets try this:
When using golang/tools@87312bc and empty "_" imports, it's easy to guess that you only have to take care of doing a specific group for it/them, goimports will not break anything. Unfortunalety with golang/tools@12a7c31 isn't that clear IMHO what you should do, and what should be the expect as output. If you run golint against both outputs:
Gives no output, passing the check.
Fails. Not saying your commit is a problem by itself, but definitively breaks the way we used to work with goimports. Until a reasonable explanation/fix is given we are pinning to golang/tools@87312bc Maybe is more of a documentation problem and there should be a document explaining what we should give to goimports as input and what we should expect as output. |
Change https://golang.org/cl/143657 mentions this issue: |
The CL that was the cause of this bug was rolled back. |
Given the following file:
goimports will incorrectly associate the comment with "bar" instead of "foo", producing this file:
This is using the latest master of the tools repo (5e66757).
The text was updated successfully, but these errors were encountered: