any update here?

as mentioned - I am willing to work on this myself and contribute it to gopls.

Any help will be appreciated.

Hi @asankov - thank you for filing this detailed issue report! You are correct in saying that these types of quick fixes are provided as code actions.

To add such a fix, we would first need to write an analysis with a suggested fix. You may find this talk given by @matloob helpful when getting started with go/analysis. Once the analysis is written, it can be added to gopls quite simply - just by adding it to this list.

You can run your own version of gopls simply by cding into golang.org/x/tools/gopls and running go install on your machine. To avoid clobbering your stable version of gopls, you can rename the development binary. You can also have per-workspace configurations for VSCode which differentiate which version of gopls to use based on the workspace.

Hello @stamblerre

Thank you for the detailed explanation. Michael's talk you refereed to and your talk from the same conference were very useful to me in getting some grasp on how goplsand analyzers work.

Regarding this issue - I was wondering whether such analyzer does not already exist somewhere. The reason being that I already get an error message in my IDE, I just don't get 'quick fixes'. I found no such analyzer in the defaultAnalyzers slice in the code you refereed, but after a bit more digging it turned out that something of the sort indeed exists:

~/go/src/github.com/golang 
$ grep -ri 'no result values expected' .
....
./go/src/go/types/stmt.go: check.error(s.Results[0].Pos(), "no result values expected")

this is the result of a grep for the error msg in the go codebase. Turns out this check is built in go vet and running go vet on the file, which I used for the screenshot yields the same error I see in my IDE. The problem is that when I looked into the code this is not an analyzer, and I don't think it will be trivial to extend it in a way that will be able to show the 'quick actions'.

So I was thinking that I can try to write a brand new analyzer from scratch and add it to the defaultAnalyzers slice in the go/tools codebase.

What's your take on that? Do you think it makes sense to write something brand new, when there already is something similar in the open, and do you think that adding such checker to gopls would conflict in some way with go vet and cause any problems to the users?

Thanks for following up! The codebase that you were looking at here is the type-checker (https://golang.org/pkg/go/types/), which gopls uses to type-check your code. Because the type-checker is in the standard library, it isn't likely that we will be able to modify it to support suggested fixes anytime soon. I think writing analyses to provide suggested fixes is likely the best approach, and it won't conflict with go vet because vet doesn't deal with syntax or type errors.

/cc @ridersofrohan

Change https://golang.org/cl/222237 mentions this issue: internal/lsp: add quickfix for undeclared variable

Change https://golang.org/cl/222761 mentions this issue: internal/lsp: add support for type error analyzers

Change https://golang.org/cl/223666 mentions this issue: go/analysis: add quickfix for "no result values expected"

Change https://golang.org/cl/225477 mentions this issue: internal/lsp/analysis: add quickfix for "no new vars on left side"

We now have infrastructure for adding a type error analysis suggested fix, and we also have the goreturns suggested fixes that would correct the original problem mentioned here. I'm going to close this issue, but there are still many other suggested fixes we could add--we can file issues for those individually.