-
Notifications
You must be signed in to change notification settings - Fork 163
VSCode text and cquery's internal representation frequently falls out of sync #792
Comments
What commit is this on? |
I have a situation where compilation of a single TU habitually takes 10+ seconds. I found that to make cquery understand my changes I have to edit, wait till cquery job count goes to zero, then edit again by adding an innocent space -- and 10+ seconds later I have working cquery again. |
I sometimes run into what OP describes where I cannot make cquery to behave and have to exit vscode, delete cache, and wait till reindex, but that's rare. I think OP's situation is a race between edits and reindexes. |
@jacobdufault Originally saw this on af7f14c, I reproduced on 37f1410 today. cquery is idle, according to the VS Code status bar entry, and I'm not experiencing any 10 second delays. Other potentially relevant info: In addition to a bunch of includes, defines and |
same for me. It is exacerbated with long compiles. |
after I stopped recording, I checked the state of
|
By default cquery only updates the index once it receives the |
the file is certainly saved because 1) I have auto-save enabled 2) git sees the file the same way vscode sees it 3) ctrl-s does nothing. This of course doesn't mean vscode sent |
Here's the link to the wiki: https://github.com/cquery-project/cquery/wiki/Debugging#dump-lsp-requestsresponses You'll have to comb through all the requests and messages. |
I'll check the contents of the index and the LSP communication next time I get the error, and report back! For the record, I do not have autosave enabled, so it's unlikely that this index update is what's causing it for me. I do have frequent Ctrl+S presses in muscle memory though, so I'll need to check the communication dump to confirm this. |
I can repro with ctrl-s only as well. Just harder to prove on video that I hit it. |
and I am pretty sure that If it is really necessary, I will of course figure out where are the LSP logs with VSCode.:-) |
@trond-snekvik I'm starting to think your issue is unrelated to @svorobiev's. I could be totally wrong. @svorobiev That indeed sounds like the notifications are firing and cquery is picking them up.
Wherever the |
where do I even specify |
I'm not a vscode user, so you'll have to read the wiki: https://github.com/cquery-project/cquery/wiki/Visual-Studio-Code#setting-up-the-extension |
Related |
I collected the log. Video with repro and log being collected here: https://youtu.be/owYfnyayEmI. Places of interest in the log are (23029.442s) [indexer2 ] and (23038.584s) [indexer5 ] which exactly correlate to me hitting ctrl-s. Log:
|
I enabled the LSP communication dump, and was able to reproduce the issue in my first screenshot. The dump pinpoints the first problem quite well, and I don't think it's the same as @svorobiev's. For some reason, my VSCode LSP client (a clean version of vscode-cquery v0.1.10) is reporting the same change three times, using the same version number for each repetition. I started out with this line (line 1662 in the LSP): if (subnet_handle >= DSM_SUBNET_MAX || mesh_config_entry_is_allocated(MESH_OPT_DSM_SUBNET_EID() which is 99 characters long. I placed the cursor between the last two parentheses (character 98 in the LSP) and wrote
As you can see, each letter is reported three times, but with the same document version number. The resulting error message is
Note how the mess after the three closing parentheses matches the reported error. Interestingly enough, the didChange command is the only notification that's repeated in the LSP communication, all the others are singular. There's only one When I restart VSCode, the client goes back to only sending a single Looking through working_files.cc, it looks like the --- a/src/working_files.cc
+++ b/src/working_files.cc
@@ -505,8 +505,11 @@ void WorkingFiles::OnChange(const lsTextDocumentDidChangeParams& change) {
return;
}
- if (change.textDocument.version)
+ if (change.textDocument.version) {
+ if (*change.textDocument.version == file->version)
+ return;
file->version = *change.textDocument.version;
+ }
for (const lsTextDocumentContentChangeEvent& diff : change.contentChanges) {
// Per the spec replace everything if the rangeLength and range are not set. |
@trond-snekvik -- you never saved the source file, correct? If so, it is definitely a different bug. |
That's correct. I believe it could be related to @Yanpas' cquery-project/vscode-cquery#50 though |
BTW this tool may be handy for debugging. |
@trond-snekvik I confirm that our issues are different. I had a repro of yours. No screenshot from me -- but it looked just like yours. |
While using cquery with VSCode, I frequently have to reload the window (restarting cquery) because of errors like these:
Note that in the first error the offending line hasn't been changed, although the ones before it were, triggering similar errors in multiple locations. The errors never seem to occur before the change that made them appear. Reverting the change that triggers the errors does not resolve them.
The error occurs randomly at a rate of once or twice per hour.
Occasionally, the error seems to resolve itself during auto completion requests around the broken area, but this seems rare, and I suspect it's just cquery crashing and restarting.
As a workaround, I think an option to run the text sync in full update mode should resolve the issue, but I don't know enough about the internals of cquery to test it myself.
The text was updated successfully, but these errors were encountered: