Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/cmd/goimports: interspersed comments can be associated with the wrong import #28200
Given the following file:
# foo.go package main import ( _ "bar" // foo has side effects. _ "foo" )
goimports will incorrectly associate the comment with "bar" instead of "foo", producing this file:
package main import ( _ "bar" // foo has side effects. _ "foo" )
This is using the latest master of the tools repo (5e66757b835f155f7e50931f54c9f6af8af86f75).
@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 12a7c317e894c0a622b5ed27f0a102fcdd56d1ad:
Hi @lopezator, let's use another instances.
In both cases it fails to place the comment.
Valid import comments:
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.
I went over your examples and your are right, both of them fail given that input.
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.
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.