Receiving "code -32600" / message "not indexed"

[madscientist]

I've started getting these errors back from ccls in my lsp-log buffer (Emacs 26.1, lsp-mode 20190126.1601, ccls-20181225.853, company-lsp-20190126.1750) for my large project. I haven't been able to reproduce this in smaller sample codebases, but I've used a stripped-down Emacs init.el and can still reproduce it. I've definitely waited for the entire codebase to index. In fact this same problem happens if I enable initialBlacklist (".") to avoid indexing the entire project at once.

Nothing is completing, no symbols are resolved, etc. I've enabled logging with -v=1 and there are no errors or strange messages, the compile lines for my source are shown in the log and all look correct to me, and there is no problem finding the Clang resource directory for headers like stddef.h etc.

I'm not sure what this error code means or what to do next to debug further.

I get things like this in *lsp-log* in Emacs:

{
  "jsonrpc": "2.0",
  "id": 26,
  "error": {
    "code": -32600,
    "message": "not indexed"
  }
}
<<<< ccls:7496
{
  "jsonrpc": "2.0",
  "id": 27,
  "error": {
    "code": -32600,
    "message": "not indexed"
  }
}
<<<< ccls:7496
{
  "jsonrpc": "2.0",
  "id": 28,
  "result": {
    "signatures": [],
    "activeSignature": 0,
    "activeParameter": 0
  }
}

[MaskRay]

A "not indexed" message is emitted here at https://github.com/maskray/ccls/blob/master/src/message_handler.cc#L279

The backlog mechanism is documented in the description of 0b80a10

When the main thread handles a message, it leaves backlog false. The first "not indexed" (backlog==false) throws an exception rather than issue an ErrorMessage.

Can you raise the initialization option request.timeout (defaults to 5000 milliseconds)?

[madscientist]

I've changed it to 50000 (50,000) milliseconds but no change in behavior. I don't see how it could take even 5 seconds to parse these files, they're not THAT big (including headers). Also since I set InitialBlacklist to "." ccls shouldn't be busy parsing lots of other files. I feel like something is stuck somewhere and not finishing the parse.

[MaskRay]

The "not indexed" ResponseError may be emitted either

• The requests takes more than 5 seconds because the file hasn't been indexed yet. This may happen (but rarely) for files with a pile of #includes.
• The file fails to index. Many problems are possible. One is that there are more than 1 input files on the clang command line. Only the first file is indexed. In the libclang land, it is strict on the one-input-file rule, c-index-test -index-file a.c a.c => CXError_Failure "Failure (no details available)".

For example, this compile_commands.json is unacceptable:

[{"arguments": ["c++", "b.h", "a.cc"], "directory":"/tmp/c", "file":"a.cc"}]`

Only b.h is indexed and when you open a.cc, there is no index for a.cc, thus the "not indexed" ResponseError.

This works, though not good:

[{"arguments": ["c++", "a.cc", "./b.so"], "directory":"/tmp/c", "file":"a.cc"}]`

[madscientist]

I believe this was caused by issue #304 . Normally I create a /work directory for all my work. However on this system due to the vagaries of partition mounting I made /work a symlink to /home/work, so my Git worktrees are at the physical location /home/work/foo/bar but when I visit them I use the path /work/foo/bar. This appears to have caused the problem.

In order to work around it I had to (a) delete the existing .ccls-cache, (b) visit the files using the real path not the symlink, and (most importantly) (c) delete and recreate my compile_commands.json file having cd'd to the worktree using the real path. Apparently CMake uses the value of $PWD rather than the real path when it locates the current working directory so if you get to the root via different means you get different paths in the JSON file.

[MaskRay]

See #314