If you want to disable code actions, I think the right syntax is "editor.codeActionsOnSave": {}. If you'd like to investigate the underlying issue here, please share a gopls log: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs.

Hey @hyangah here's a trace.

vscode_hangup.txt

It looks like your log may be incomplete--I would expect it to start with an initialize request. Do you mind sharing a complete log starting from the initialization?

Also, I notice that there are 2 extensions listed in the pop-up here--does disabling the "GitHub Pull Requests and Issues" extension fix the problem?

@stamblerre did you read the attached text file as well? It covers the whole period of the hangup, not all they way from the start of vs code. Isn't that enough?

Yes, I did read that file, but gopls logs useful debugging information at start-up, which is why it would be best to have a log starting at initialization. If that's not possible, you can run gopls -rpc.trace -v check path/to/file.go in your VS Code workspace root.

@stamblerre here's one all the way from the beginning
Untitled.txt

On further usage, right now, when I e.g. run the tests, the Go extension starts compiling the program. If I cancel the tests, it doesn't stop the compilation, it keeps running on the remote server. Now every time I save a Go file it stalls for 2 minutes as it's waiting for the compilation to end.

Edit: actually, whenever I save a file, it starts compiling the whole program. If I save numerous time one after another, for each save, it starts the whole process of compiling the program. It's a cgo program.

Hey @stamblerre any updates on the topic? I suppose we are still not "waiting for info"? This makes VS code impossible to use for me

Apologies, I must've missed your response. Does setting "go.useLanguageServer": false resolve the problem temporarily while we investigate?

On further usage, right now, when I e.g. run the tests, the Go extension starts compiling the program. If I cancel the tests, it doesn't stop the compilation, it keeps running on the remote server. Now every time I save a Go file it stalls for 2 minutes as it's waiting for the compilation to end.

Edit: actually, whenever I save a file, it starts compiling the whole program. If I save numerous time one after another, for each save, it starts the whole process of compiling the program. It's a cgo program.

Ah, I see it's also related to running the tests. Does it work if you don't run the tests, or are the saves still slow then?

It's unrelated to testing, although "Build on save" is set to package, the default value

That setting doesn't actually apply when the language server is enabled. To follow up on some of my earlier questions:

• Were you able to disable code actions by setting "editor.codeActionsOnSave": {}?
• Does disabling the "GitHub Pull Requests and Issues" have any effect?
• Does setting "go.useLanguageServer": false resolve the problem temporarily while we investigate?

Hey @stamblerre still seeing this issue.

• Disabling Github Pull requests doesn't have any effect
• Setting language server false does indeed help
• "editor.codeActionsOnSave": {} indeed does remove the stalling yet on saving it does run gofmt (or similar) on my file

"editor.codeActionsOnSave": {} indeed does remove the stalling yet on saving it does run gofmt (or similar) on my file

You can set "editor.formatOnSave": false to disable formatting.

That's fine. The big issue still is that it tries to build my Go project each time I save the file. Being a cgo project, that takes several minutes.

Is this still happening with "go.useLanguageServer": false? If so, then you can try setting "go.buildOnSave": "off".

Hey @stamblerre please see my previous comment 6 hours ago, in which I explained that it is indeed not happening when I set go.useLanguageServer false.

Thank you for the clarification. I've transferred and retitled this issue, and we will try to investigate it more thoroughly when possible (likely not in the next month). In the meantime, we hope the workaround of disabling the language server will be sufficient.

I've noticed huge lag/deadlock with gopls as well and initially attributed it to a large package set (some recent work was done for that, but still seeing intermittent deadlocks now). But perhaps this has bearing as well since my project I believe relies upon some c-libraries. These periodic machine hangs where I see gopls pegging my cpu at 290% for 10-20 seconds at a time make me want to just turn it off.

@mrjrieke: Can you please open a separate issue so that we can investigate your problem separately? Please include the information requested in the troubleshooting guide.

I think this may in fact be fixed at last (for me at least). Re-enabled Language Server in vscode. I am on latest version go gopls available to me anyways:
golang.org/x/tools/gopls v0.12.1
golang.org/x/tools/gopls@v0.12.2 h1:s4mznBqCHVHeuTYjxGYJhsW3Wp4FYon8YAqiJlwlpTY=

I now have a pleasant debugging experience in the project I was trying to develop in vscode that prior caused my machine to brick.

Thanks for all the hard work that went into gopls to improve the performance.

Thanks @mrjrieke.

I think this is no longer actionable: there is a high initial cost for the cgo build (same as you would experience from the command line), but after that things should be fact.