gopls stops working if you write sufficiently complex code in Go 1.18 #4098
Assignees
Labels
Comments
|
I found the source of this and fixed it now. When the LSP programs crash we don't clear the data in ALE. It was a crash in |
liskin
added a commit
to liskin/ale
that referenced
this issue
Jul 20, 2022
When 'close_cb' is set for job_start(), but out_cb or err_cb isn't, vim buffers data instead of dropping it (in case someone wanted to read and process it in close_cb), and additionally polls for new data every 10 milliseconds, causing excessive wakeups and CPU usage. Since we don't read the data anywhere outside of out_cb/err_cb, any LSP that prints an error to stderr triggers this and vim keeps spinning until :ALEStopAllLSPs. Fix this by always setting both callbacks, thus dropping any data we're not interested in. See vim/vim#10758 for an upstream report of the excessive polling. It's possible this is intentional, I dunno. Fixes: b42153e ("Fix dense-analysis#4098 - Clear LSP data when servers crash")
hsanson
pushed a commit
that referenced
this issue
Jul 26, 2022
When 'close_cb' is set for job_start(), but out_cb or err_cb isn't, vim buffers data instead of dropping it (in case someone wanted to read and process it in close_cb), and additionally polls for new data every 10 milliseconds, causing excessive wakeups and CPU usage. Since we don't read the data anywhere outside of out_cb/err_cb, any LSP that prints an error to stderr triggers this and vim keeps spinning until :ALEStopAllLSPs. Fix this by always setting both callbacks, thus dropping any data we're not interested in. See vim/vim#10758 for an upstream report of the excessive polling. It's possible this is intentional, I dunno. Fixes: b42153e ("Fix #4098 - Clear LSP data when servers crash")
mnikulin
pushed a commit
to mnikulin/ale
that referenced
this issue
Nov 12, 2023
…#4259) When 'close_cb' is set for job_start(), but out_cb or err_cb isn't, vim buffers data instead of dropping it (in case someone wanted to read and process it in close_cb), and additionally polls for new data every 10 milliseconds, causing excessive wakeups and CPU usage. Since we don't read the data anywhere outside of out_cb/err_cb, any LSP that prints an error to stderr triggers this and vim keeps spinning until :ALEStopAllLSPs. Fix this by always setting both callbacks, thus dropping any data we're not interested in. See vim/vim#10758 for an upstream report of the excessive polling. It's possible this is intentional, I dunno. Fixes: b42153e ("Fix dense-analysis#4098 - Clear LSP data when servers crash")
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Information
VIM version
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug 29 2020 14:11:37)
Included patches: 1-1539
Operating System: Linux
What went wrong
If you write very complex code that causes
goplsto freak out something goes wrong with the messages between ALE andgoplsand you can't see errors in your editor until the code is modified and you restart the server with:ALEStopAllLSPs. It might be that the server is panicking with code it can't understand and ALE need to handle the server crashing better, or that the messagesgoplsis sending aren't understood by ALE.Reproducing the bug
Reproducing this is complicated. I'm going to have a look at it.
:ALEInfo
N/A
The text was updated successfully, but these errors were encountered: