Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: improve completion results when they depend on code after the current line in the same file #43471

cespare opened this issue Jan 3, 2021 · 1 comment


Copy link

@cespare cespare commented Jan 3, 2021

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

1.15.6 / gopls 0.6.0

Does this issue reproduce with the latest release?


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



A problem I frequently encounter using gopls is that if the completion target depends on code defined in the same file but after the cursor position, the completion is non-functional unless the expression is extremely simple.

Here are some concrete examples using vscode.

If the type S is defined before the current function and I start typing a range statement, completion works fine:


If the type S is defined after the current function and I start typing a range statement, completion is not useful (it suggests some irrelevant packages):


An if expression has the same problem:


But if I only type a simple s., completion works:


I understand that the problem of trying to parse partial (i.e., broken) code is, in the general case, impossible. But doing a passable job in the typical cases seems important. ISTM that a heuristic as simple as "try parsing the code after deleting the line that the cursor is on" would cover the examples I showed here and most of the instances I notice day to day.

I looked for an existing issue as best I could with GH issue search but didn't find anything.

@gopherbot gopherbot added this to the Unreleased milestone Jan 3, 2021
Copy link

@muirdm muirdm commented Jan 3, 2021

try parsing the code after deleting the line that the cursor is on

The problem with that approach is that we need to parse the current line to know we are completing s. (i.e. to look for fields on the S struct).

See for a previous relevant fix. Adding phantom curlies (i.e. if s. {}) and re-parsing is one way to make things work. Perhaps fixMissingCurlies can be tweaked in some way to fix this case as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.