x/tools/gopls: inaccurate completion results for partial function call syntax inside an if condition

[findleyr]

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:

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.

[muirdm]

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]

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! :)