Turning on log_debug gives me a hint that it stops calling LSP: <-- textDocument/publishDiagnostics when it happens.
Turning on log_debug and log_stderr fixes the issue (not getting stuck at all), but I can see multiple server: E[22:08:10.458] Error -32601: method not found errors.
After the diagnostics hang, do you still get completions?
I can see multiple server: E[22:08:10.458] Error -32601: method not found errors.
clangd prints this when it doesn't recognize an LSP request. Can you provide the LSP request just before the method not found message?
Ok, so it appears every time LSP: --> textDocument/didSave is triggered and at the very beginning after LSP: --> initialized
LSP: --> textDocument/didSave
server: I[08:29:16.111] <-- textDocument/didSave
server: E[08:29:16.111] Error -32601: method not found
Also it doesn't matter if I place compile_commands.json in build folder or not. The only difference is in showing message about its presence server: I[08:54:21.888] Failed to find compilation database for..., but other behaviour is the same - with full debug info on, everything works fine, but without stderr it hangs.
After diagnostics hang I don't get clangd completions, only built-in Sublime completions.
clangd does not care about the textDocument/didSave and initialized notifications: https://github.com/llvm-mirror/clang-tools-extra/blob/ffb1f50bc16186bdfc2f6efeea11a62396fe8ead/clangd/ProtocolHandlers.cpp#L47-L79
So while that may look alarming it's not actually an error.
Also it doesn't matter if I place compile_commands.json in build folder or not.
You need to copy the compile_commands.json file to the root of your workspace, otherwise clangd won't pick it up.
After diagnostics hang I don't get clangd completions, only built-in Sublime completions.
I've noticed that if there are tons of diagnostic errors, clangd won't supply completions anymore.
I've noticed that if there are tons of diagnostic errors, clangd won't supply completions anymore.
Can it be the problem with flushing buffer or something similar? Because as I said - setting log_stderr to true fixes the problem (don't know for how long, but at least longer than without it).
And yeah, compile_commands.json is present in the root of my workspace, sorry for naming it "build folder".
does it produce non sense errors such as "\
Is there a support forum for clangd?
One benefit with cquery is the ability to search and ask for help at their GitHub repo: https://github.com/cquery-project/cquery
@tomv564 What is the point in closing unsolved issues? Yes, my workaround with turning on all debug info is working, but it's not a fix for the plugin itself. Probably I can help somehow fixing it, but except Python background I've never worked with Sublime plugins development, so some hints where to start will be much apprecieated. Sorry for not asking you about it earlier.
I know that ODatNurd has some good videos on how to start building plugins. But you could also visit the sublime text API, and figure it out yourself.
I closed the issue because despite a few comments, this discussion was not getting any kind of clarity. But since you're still motivated let's have a closer look!
Your theory about stdio buffers not flushing is plausible, can you configure clangd to not log to stderr at all and see if the issue disappears?
The message that should lead to a publishDiagnostics is likely didChange. Does the server log that it receives didChange, and if you increase clangd's logging verbosity do you see some change in the logging output when it stops sending diagnostics?
In case the file/view itself (and not the whole server) gets stuck:
Does closing and re-opening the file get the file's diagnostics to start appearing at the right place again?
In the case of restarting not working:
Can you share logs of both this package and the server's logging when this happens?
Thank you guys, I'll learn some new things and try to help :)
I'll investigate it more and try to get all the data you asked for, but for now:
log_stderr fixes the issue.-log=error also helps (but I'm not sure for how long, because 3.)process.PIPE and it seems that it can get stuck if not flushed (if we enable log_stderr, it's redirected to logger, so it's flushed and everything is fine).Nice troubleshooting and thanks for sharing documentation, too!
When you reproduce the issue, does clangd stop responding to other requests (hover) as well?
We could fix the case where log_stderr is off by redirecting stderr to subprocess.DEVNULL instead. Another option is to always create a thread to consume it, and simply not log anything.
What do you think?
Setting stderr=subprocess.DEVNULL in start_server() inside process.py works, so if we are ignoring those errors anyway (if log_stderr is off), I think that redirecting them to DEVNULL by default is a nice solution :)
Hi @Listwon, at work I actually experience the same problem. And your suggested fix keeps clangd working. I suggest you turn your idea into a pull request ;)