EnableIndexOnDidChange not working as expected

[joaotavora]

I'm building Eglot, an alternative Emacs client to cquery.

It's coming along fine and cquery behaves nicely (the latest "Lantern Festival" release, that is, because I can't get the latest master to build, see #691).

Anyway I'm having trouble when renaming symbols (which leads to a didChange notification from client to server). I suspect cquery's view of the file's state has become corrupted. I don't know if it is my client's fault or cquery's. Is there a way to query cquery about what it thinks a file's contents are, or do I have to hack the code and put a giant printf there??

[joaotavora]

Well, I did the printf hack and it solved me problem:

diff --git a/src/working_files.cc b/src/working_files.cc
index 83fa7eab..39b91ad5 100644
--- a/src/working_files.cc
+++ b/src/working_files.cc
@@ -524,6 +524,8 @@ void WorkingFiles::OnChange(const lsTextDocumentDidChangeParams& change) {
       file->buffer_content.replace(file->buffer_content.begin() + start_offset,
                                    file->buffer_content.begin() + end_offset,
                                    diff.text);
+      LOG_S(WARNING) << "Here are some contents:\nSTART\n " << file->buffer_content
+                     << "\nENDENDEND";
       file->OnBufferContentUpdated();
     }
   }

This shows that cquery's view of the file has not become corrupted as I suspected.

Unfortunately, after renaming a symbol, or after simpler bits of editing, highlighting for the new symbol name stops working correctly, returns invalid regions or stops working altogether. It starts working again after a didSave. Is this a known problem?

I have renamed the issue. It is also being analysed at joaotavora/eglot#9

[joaotavora]

FWIW, the same problem happens with the emacs-cquery client.

[jacobdufault]

Unfortunately, after renaming a symbol, or after simpler bits of editing, highlighting for the new symbol name stops working correctly, returns invalid regions or stops working altogether. It starts working again after a didSave. Is this a known problem?

The document is not reindexed until you save a file. cquery has heuristics to make this work a bit better, but it is not perfect.

You can set enableIndexOnDidChange to reindex on edit.

This is off by default because it is too slow for large projects - cquery defaults are optimized for large projects.

[jaelsasser]

I was able to reproduce this even with enableIndexOnChange passed through in the initialization params. From the discussion over in eglot:

I can definitely confirm that cquery seems to end up with corrupted file contents after applying workspace edits. I renamed a priv variable to adapter and got a weird document state. I then added :enableIndexOnChange t to cquery's eglot-initialization-options and got better results (apparently its disabled by default) and started getting back pter: struct ctx_priv *priv = NULL in eldoc and highlights that only covered pter.

I dug around for a bit this last weekend and couldn't track down a root cause. I'm planning on spending a bit more time shooting this this weekend, though.

Edit: just to clarify, after renaming a symbol, autocompletion works with the new name (in my above example, I can access all of priv's members), but a handful of things break:

• textDocument/hover returns corrupted variable signatures (pr: sruct ctx_priv old_name)
• goto definition cannot find the new symbol name
• symbol highlighting only returns highlight ranges for a subset of the symbol name (i.e. priv vs priv)

[joaotavora]

I have renamed the issue, I hope you can reopen it in light of what I explain below.

(BTW, @jaelsasser the option's name is enableIndexOnDidChange not enableIndexOnChange. It doesn't make a difference though, I even tried it by edit and recompile)

@jacobdufault, I can confirm that even after enabling enableIndexOnDidChange I get the strange behaviour. I can't understand why, since I poked around in the message handler classes for didSave and didChange and made them do basically the same. My guess would be that symbol location discovery is taking the file-system representation into account, not its temporary in-memory representation.

Also, in the didChange handler, I confirmed that the changes that the Eglot client sends in are being correctly parsed and applied to the in-memory copy.

[joaotavora]

@jacobdufault, ping?

Can you confirm that you've read my last message? Are you aware of any language server client that sends enableIndexOnDidChange and obtains the behaviour you describe?

[jacobdufault]

My guess would be that symbol location discovery is taking the file-system representation into account, not its temporary in-memory representation.

Yes, this sounds reasonable. Need to investigate though.