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

$ go version
go version go1.15.6 linux/amd64

Does this issue reproduce with the latest release?

Yes, and with the current tip of gopls as well.

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

I can reproduce this with basically any code.

But concretely, I used this single-file package:

package main

func f(int) {}

func x() {
    n := 3
    m := 4
    f(|)
}

The | is where my cursor is when I invoked autocompletion.

What did you expect to see?

I expected to see completions that make sense given the types involved. Whatever the completions I saw, I expected that if I invoked autocompletion a second time without making any change whatsoever, I should see the same list of suggestions again.

What did you see instead?

I saw a long list with many irrelevant suggestions. Additionally, every time I invoked autocompletion, the list was different.

I noticed this in my usual environment (vim + govim) but I can reproduce with vscode as well. Here are some screenshots (I pressed ctrl-space three times in a row and got these three results):

screen_20201224235014

screen_20201224235025

screen_20201224235033

Comment From: myitcv

Drive-by guess: candidates have an equal score and there is no ordering defined across them, hence the seemingly "random" behaviour.

FWIW I've also struggled with the verbose nature of deep completions (which is why you see the crypto.BLAKE* candidates above, I believe). The unfortunate thing is that in certain situations they would be incredibly useful - but the noise in the 90% of cases is what makes them unusable for me. It feels like this is the very nature of the beast - i.e. there isn't a way to turn down the noise and keep the useful cases alive. But I could very well be totally wrong on that.

Comment From: muirdm

I believe they change as more unimported packages are processed in the background. Do they not stabilize eventually?

Basic objects (e.g. ints, strings) from unimported packages are probably very rarely selected as completion candidates, so maybe we can completely omit them. Or perhaps have a minimum prefix requirement before they show up.

Or even better maybe we could go down to showing a single deep completion candidate (instead of three), and only show it if it is the top scoring candidate.

Comment From: gopherbot

Change https://golang.org/cl/311069 mentions this issue: lsp/completion: omit deep completions into unimported packages

Comment From: muirdm

If interested, please try out https://go-review.googlesource.com/c/tools/+/311070/1 . I'm going to use it for a bit and see if there are any places it doesn't offer a completion I expect.

Comment From: SOF3

would also be useful if completion inside a struct literal prioritizes field names over expressions, since most struct literals are named.