-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration with SublimeLSP stopped working #161
Comments
Actually, I synced all the way back to June and I'm hitting the same issue, so I'm now assuming this is on the SublimeLSP side. Will close for now, sorry for the noise! |
Note that the specification mentions its valid to have a |
Yup that's exactly what's going on here:
|
Btw my bisection results were actually incorrect because I forgot I need to restart the LSP server each time :( But the issue is in requestConfiguration handler:
configIt here points to a JSON "null" object; the entire response for configuration is |
Do you mind sending over the LSP settings you are using? |
Also, enabling |
|
Fixed this bug. This was the only issue I could find, I couldn't reproduce the initial one. Let me know if it continues to occur |
I'll need to spend more time on this tomorrow. It's fairly puzzling:
Unrelated, the only other message I get from luau-lsp now is "luau: unknown notification method: textDocument/didSave" - does luau-lsp produce some other method like |
This is completely normal. Yeah, we listen to didChange instead. We just haven't registered a handler for didSave because we don't need one right now. We could probably silence the warning though |
Ok thanks. Apologies if this one is unrelated - please bear with me, as I'm trying to basically identify every single thing that I know is guaranteed wrong, so that only spurious unidentified failures remain :) - but one other quirk is that sometimes (often) when I open the file for the first time in a new Sublime window, I don't get any diagnostics until making a dummy change to the file. Looking at the log, it looks like Under these circumstances, is the LSP client (Sublime) responsible for sending textOpen again?
|
Yeah, I spotted this too, and you are correct - this is because the didOpen notification was sent before we received configuration. (This check is mainly here to stopped the inverse happening - loads of false positive diagnostics in Roblox code because the default constructed config has Roblox support disabled) The logic is somewhat flawed for push diagnostics. The server is mainly setup for pull diagnostics mode (which is the newer method), but Sublime does not yet support it, so we fall back to legacy push diagnostics. didOpen should only be sent once. The issue is on the server side here. If we are in push diagnostics mode, what we should probably do is re-push all diagnostics for all currently opened files when the config changed callback is run ( luau-lsp/src/LanguageServer.cpp Line 364 in b609ead
(just noticed, we already do half of this, but only when whole workspace diagnostics is enabled) |
After all these fixes I can't reproduce the problem anymore 😅 I'm going to wait until the next binary build so that I can confirm that on an executable built externally, and then hopefully close this. The only identifiable problem that is left is the exception in Sublime LSP from the OP, which manifests on some errors, but that's a bug on their end that I'll submit a PR for. |
This used to work just fine, but after updating to a more recent version of luau-lsp (apologies, I haven't noted the last version that worked) I'm getting this:
The Python code that errors is
I'm assuming that "id" is set to null in the JSON response... I'm going to try to bisect this but I wanted to file this first in case it's something obvious.
The text was updated successfully, but these errors were encountered: