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: inaccurate completion results for partial function call syntax inside an if condition #54374

Open
findleyr opened this issue Aug 10, 2022 · 2 comments
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Contributor

findleyr commented Aug 10, 2022

Reported on Slack:

When typing out a function call inside an if condition, gopls provides incorrect completion results, apparently due to inferring that it is completing a type name:

image

Generally gopls struggles with partial syntax and imbalanced delimiters, but in this case specifically it seems like we can do better. For example, the same syntax outside of an if condition generally works.

@findleyr findleyr added this to the gopls/later milestone Aug 10, 2022
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Aug 10, 2022
@muirdm
Copy link

muirdm commented Aug 13, 2022

Looked briefly. We have a source fix that adds missing "{}" curlies to *ast.BlockStmts that are missing curlies in the source. Things parse really poorly when curlies are missing, and this helps. However, in this case with the closing paren missing, we convert this:

if foo(bar

Into:

if foo(bar{}

After parsing, "bar{}" looks like a composite literal, so we expect a type name.

If I were to not think very hard and do something, it would be to add another pass to stick missing closing parens in the source. But, all these fixes have really turned into a mess. Maybe a better workaround is to disable the only-offer-type-name-candidates filtering if we have doctored the source.

@findleyr
Copy link
Contributor Author

findleyr commented Aug 13, 2022

Thanks for looking into this Muir. I think disabling the filter makes sense.

Aside: don't feel obligated to send a CL. We can take care of it! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants