Go: x/tools/gopls: support autocompletion of unimported packages

[stamblerre]

See for https://github.com/Microsoft/vscode-go/issues/2484 for context.

[ramya-rao-a]

When this does get into gopls please send a PR or log an issue to the vscode Go plugin so that we can disable the similar feature (in non module mode) there to avoid duplicate suggestions

[zchee]

@stamblerre
Just a question.
Is this issue means only of stdlib like gocode?
Or, all of packages ingo.mod?

[stamblerre]

It would be all available packages, not just stdlib.

[zchee]

@stamblerre
great.

Are you doing now develop this feature?
I do not know what you remember to me, but I maintained nsf/gocode for a while. If you not yet develop this feature, I would want to help you.

[stamblerre]

I am not actively working on it yet, so you're absolutely welcome to get started on it.

[jackielii]

@stamblerre @saibing I found out that this is a difference between https://github.com/saibing/tools & https://github.com/golang/tools/tree/ : saibing/tools already have this feature:

screenshot from saibing/tools + coc.nvim + neovim nightly build

[stamblerre]

From https://github.com/microsoft/vscode-go/issues/2575:

There are really two components to this issue. For example (in both cases, time is not imported):
1) Typing "ti<>" and getting package time as part of the autocompletion results.
2) Typing "time.<>" and getting autocompletions for the members of package time.

[suzmue]

https://golang.org/cl/190338 adds support for autocompletion of unimported standard library packages

This supports autocompletions in the first case listed above

1. Typing "ti<>" and getting package time as part of the autocompletion results.

[heschik]

At master, gopls now supports completing all unimported packages. There may still be performance issues, but the functionality exists.

[islishude]

It works now!

[chengyayu]

It works now!

does it works for go modules gpls? which version is it ?

[chengyayu]

versions

• vscode : 1.39.2
• vscode-go: 0.11.7

my settings

 // go settings
    "go.buildOnSave": "off",
    "go.lintTool":"golangci-lint",
    "go.lintFlags": [
        "--fast"
    ],
    "go.useLanguageServer": true,
    "go.languageServerExperimentalFeatures": {
        "documentLink": false,
        "format": true,
        "autoComplete": true
    },
    "[go]": {
        "editor.snippetSuggestions": "none",
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        }
    },
    "gopls": {
        "usePlaceholders": true,
        "completeUnimported": true,
    },

when i type this codes go internal package can be auto import, but third party package in my go.mod can not be import.

gopls output error

[Info  - 5:23:18 PM] 2019/10/22 17:23:18 no completions found
    Failure = cannot resolve grpc

[stamblerre]

We don't yet have the exports loaded for the unimported packages, so it won't complete if you type grpc.. However, if you begin typing grpc, you will see the completions suggestions pop up, and then when you select one and hit enter, the corresponding import will be added so you can then add the period and get further completions from the package.

[chengyayu]

https://github.com/golang/go/issues/31906#issuecomment-545056493

Sorry No suggestions pop up

[stamblerre]

@chengyayu: Are you using gopls at master? To install it, you have to clone the repo, cd into the gopls directory and run go install.

[chengyayu]

@chengyayu: Are you using gopls at master? To install it, you have to clone the repo, cd into the gopls directory and run go install.

yes! it works! thanks for your suggestions.

[neoli0222]

Does anybody know how to make this work for YCM in vim? I've tried to update the code of gopls (in YCM) to master, but the completion of unimported packages still doesn't work.

[110y]

When we're using go mod and enabling completeUnimported, gopls seems to suggest all modules in module caches. As a result, too many modules appear as candidates.

I think it is helpful that gopls only suggests modules that the project we are editing are depending on excepting indirect modules, isn't it?

[stamblerre]

We haven't yet implemented ranking for unimported candidates, but I think that issue can be solved with improved rankings. The ordering should probably be something like standard library packages are preferred over dependencies in the main module followed by packages in the module cache.

We still want to suggest packages from the module cache that haven't been added as dependencies because users may still be interested in importing them.

[110y]

@stamblerre

Thank you for your response!

The ordering should probably be something like standard library packages are preferred over dependencies in the main module followed by packages in the module cache.

It sounds good!

We still want to suggest packages from the module cache that haven't been added as dependencies because users may still be interested in importing them.

I think we have several different needs for completeUnimported like below:

1. do not complete unimported packages.
2. complete only standard packages.
3. 2 + direct dependent modules.
4. 3 + indirect dependent modules.
5. 4 + all module caches.

So, I think it is better that gopls provides the option to control completeUnimported behaviour (or change completeUnimported option from just bool type to string type like hoverKind) in addition to sorting you mentioned.
How about this?

[ianthehat]

I don't think the number of results matters, only the order in which they appear.
So long as the ranking is good, there is no need for any kind of control of filter of the nature you suggest, the editor can just limit the total number of candidates shown.

[gopherbot]

Change https://golang.org/cl/204203 mentions this issue: internal/imports: sort import candidates by "relevance"

[gopherbot]

Change https://golang.org/cl/204204 mentions this issue: internal/imports: provide export completions for unimported packages

[hbd]

@110y to @ianthehat's point, why have yet another option (or n+ options), if instead the packages are ranked by some hierarchy? e.g. (autocompletions ranked first to last)

1. imported packages
2. stdlib
3. unimported packages
4. ...

more options = more complexity = harder to maintain and for new users to understand

[heschik]

I think the only thing left to do here is turn it on by default.

[muirdm]

What about the increased completion latency when there are a lot of unimported packages?

[zulhfreelancer]

@heschik

I think the only thing left to do here is turn it on by default.

How to turn it on currently?

[stamblerre]

You can add the following to your VSCode settings:

"gopls": {
    "completeUnimported": true
}

[zulhfreelancer]

UPDATE

Working now after upgrading to Go 1.13.4 — sorry for the trouble.

---

@stamblerre thank you. Any idea why this popup keeps showing?

I already have gopls installed by pressing that _Update_ button. I also tried cloning github.com/golang/tools repo, and ran go install inside the gopls folder.

The popup remains there everytime I opened VS Code. Quitting doesn't help.

My environment:

• OS: Mac OS 10.12.6
• Go: go1.11.4 darwin/amd64
• GO111MODULE: on
• gopls: version 0.2.0, built in $GOPATH mode
• VS Code: 1.40.1 (commit 8795a9889db74563ddd43eb0a897a2384129a619)

[gopherbot]

Change https://golang.org/cl/214947 mentions this issue: internal/lsp/source: enable unimported completions by default