x/tools/gopls: struct completions

[diogox]

gopls version

golang.org/x/tools/gopls v0.20.0

go env

N/A

What did you do?

In Zed, with gopls enabled, I type:

type Demo struct {
  Field1
}

func main() {
  d := De[...]
}

Where [...] is where my cursor is.

What did you see happen?

gopls suggests Demo as a completion.

What did you expect to see?

gopls knows d := Demo is not valid, as it rightly complains with Demo (type) is not an expression (compiler NotAnExpr).

Therefore, I would expect it to suggest Demo{} as the only valid completion for this instance.

Other possible scenarios where Demo might be valid, such as d := make(chan Demo) are clearly not applicable at the point of completion.

Editor and settings

No response

Logs

No response

[diogox]

To add to this, gopls suggests Demo{} just fine for return statements, for eg. So this feels even more inconsistent.

Is there a reason for this behavior that I'm missing?

Jetbrains Goland offers up the proper completion and it would be nice to have it standardized in gopls.

[gabyhelp]

Related Issues

• x/tools/gopls: improve completion suggestions #37656 (closed)
• x/tools/gopls: support fill struct behavior #37576 (closed)
• x/tools/gopls: empty struct literal providing incorrect completion suggestions #45739
• x/tools/gopls: completion for struct literal inserts package name even if already in prefix #34872 (closed)
• x/tools/gopls: superfluous {} added to first completion result for named struct type #36655 (closed)
• x/tools/gopls: consider using &S form instead of *S for pointer type struct field autocompletion #39227
• x/tools/gopls: no completions provided in some seemingly straightforward cases #69492
• x/tools/gopls: invalid completions on RHS of ":=" #39203 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[pjweinb]

The key difference is that in func f() Demo { return De^} it knows the exact type it is constructing, whereas in func f() { d := De^..} it does not. In the implementation there is a specific test for this with the comment
// Only suggest a literal conversion if the exact type is known.

It is not immediately obvious how to fix this behavior without breaking other things.

[diogox]

I have since realized that you can have the following valid alternative completion:

d := Demo(CastsToDemo{})

So I think that's why that test may be in place.

Still, the vast majority of times this is not what the dev wants to do.

And in those cases I would not mind manually replacing the autocompleted {} with ().

Is there any way we can have an option for this? Devs can opt-in if they prefer the behavior.

[xieyuschen]

In this case, it's better to suggest Demo{}, so the code change will change the if block of // Only suggest a literal conversion if the exact type is known.. The code change may require more tests to ensure it doesn't cause regression. I would like to have a try to support it.

One drawback of this improvement is that some type objects must be constructed through constructor, for example, os.File or reflect.MapIter, and it's out of scope for gopls to check whether constructor is the only possible way. I prefer to allow structure literal and accept the suggested structure literal might not be helpful, as it's still an improvement.

[pjweinb]

Demo is the start of a possibly useful completion.