goimports: provide own goimports

[dominikh]

Given our efforts on caching/indexing type information, we can provide a much faster, and slightly more accurate, goimports. This would primarily be of interest as part of the Language Server efforts (as the LS is guaranteed to have an up to date index at all times), but could be useful standalone, too.

The standalone version would have to ensure that the index is up to date. Specifics TBD.

There are two separate ways we can provide our own goimports

1. Simply provide a virtual go/build.Context for the original goimports to use. This context would use our cache.

2. Write our own goimports from scratch that queries the index directly. This would likely be faster than the first approach. It would also be necessary for implementing more accurate (i.e. more type aware) package selection.

[dmitshur]

The original goimports works on a single input .go file at a time, so it has some limitations as a result of that. For example, it can't tell if gl.ClearColor refers to the some gl package, or an unexported variable named gl in another .go file.

When you say, "slightly more accurate", do you mean this goimports would have the entire Go package as input and thus be able to resolve this limitation?

[dominikh]

It would have access to the whole package, yes. I was also thinking of the situation where you have two packages called foo with the same function Bar, but with different signatures or return types. If one choice results in valid code, and the other choice wouldn't compile, we can make the right choice.

[dominikh]

This is no longer relevant. We've given up on our index ideas and chosen a much simpler caching based approach, which goimports won't benefit from. We're not working on a language server anymore, either.