x/tools/cmd/goimports: doesn't handle packages named "v1", etc

[mattmoor]

What version of Go are you using (go version)?

$ go version
go version go1.11 linux/amd64

I'm seeing a bad format with goimports at commit: 1c3d964

You can see the bad formatting turned into a PR here: knative/pkg#176

The comment run is what's in the PR description (minus the -s, it's WIP).

cc @bradfitz

[mattmoor]

I see this with the head of release-branch.go1.11 as well.

[bradfitz]

Don't name your packages v1, I guess?

[mattmoor]

Yeah this blows up on anything touching K8s :P

[bradfitz]

Was this caused by https://go-review.googlesource.com/122616? (golang/tools@893c2b1)

Curious whether/how people think we should fix this.

@rsc @heschik @bcmills @dmitshur @kevinburke @Gnouc @josharian @mvdan @fraenkel @haya14busa

[bcmills]

See also #28435.

[bcmills]

Curious whether/how people think we should fix this.

If v1 is used as the Expr in a SelectorExpr, then goimports should not remove packages that end with the suffix v1. (It's fine if it doesn't add them, though: v1 is a terrible name for a package.)

We can compute the set of “names that might be package names” in an O(N) scan over the source file.

[bcmills]

As a workaround, what happens if you rename the package explicitly on import?

That is, change

import (
	"k8s.io/api/core/v1"
)

to

import (
	v1 "k8s.io/api/core/v1"
)

?

[heschi]

I haven't looked at this closely but I believe Bryan's suggestion will fix it, and my fix for #28428 will add the v1 automatically.

[heschi]

Give https://golang.org/cl/152000 a try?

[heschi]

Confirmed that tip goimports now adds the v1 name to the import rather than deleting it.