Sourcekite code: -32603

[Lavmint]

I successfully configured vscode to run with sourcekit-lsp, however it is extremely slow and I wanted to try sourcekite so I added path to sourcekite and changed mode but getting on every edit:

[Error - 1:16:57 AM] Request textDocument/completion failed.
  Message: Request textDocument/completion failed with message: Cannot call write after a stream was destroyed
  Code: -32603 

sde: 2.10 vscode: 1.45.1 5763d909d5f12fe19f215cbfdd29a91c0fa9208a x64

[haifengkao]

I know sourcekit-lsp is very slow, so I made a faster version https://github.com/haifengkao/fast-sourcekit-lsp/releases The problem of sourcekit-lsp is that it will return all symbols for every keystroke. I add pre-filtering to remove the symbols which do not match the text typed before the cursor.

I don't use sourcekite, though.

[Lavmint]

I know sourcekit-lsp is very slow, so I made a faster version https://github.com/haifengkao/fast-sourcekit-lsp/releases The problem of sourcekit-lsp is that it will return all symbols for every keystroke. I add pre-filtering to remove the symbols which do not match the text typed before the cursor.

I don't use sourcekite, though.

@haifengkao I already found fast-srckit yesterday, however I was not able to build it on my linux machine with

../checkouts/indexstore-db/lib/CIndexStoreDB/CIndexStoreDB.cpp:20:10: fatal error: 'Block.h' file not found
#include <Block.h>
         ^~~~~~~~~

[haifengkao]

The problem has nothing to do with fast-sourcekit-lsp. I didn't add any new header. I believe you could not build sourcekit-lsp as well.

The sourcekit dev says you need agt-get install libblocksruntime-dev https://forums.swift.org/t/sourcekit-lsp-build-error-on-ubuntu-docker/21591/4

[Lavmint]

@haifengkao I was able to build fast-srckit in my case as an archlinux user I had to install from AUR:

yay -S libblocksruntime
yay -S libdispatch

I tried to use fst-srckit with vscode, it's really fast compared to stock c:

[Lavmint]

I played around a little bit and getting a crush: 1) open project generated with swift package 2) create new *.swift file in the same folder as main.swif, info: sourcekit-lsp[264878:e4916700] could not open compilation database for %filename% 3) declare top level function 4) crush (red message) and server is not restarting

Is this a known issue or am I missing smth?

[haifengkao]

I don't have this issue. I use it everyday without any crashes.

[haifengkao]

my settings

[Lavmint]

@haifengkao I found this thread:

It looks like your Swift toolchain and the copy of sourcekit-lsp are out of sync. But I don't really see a Swift 5 branch for sourcekit-lsp /cc @blangmuir

So I considered that original source-lsp would not have this problem cuz it's in sync with current installed swift in my linux. I switched to original path of source-lsp in settings

Somehow, this time original source-lsp works amazingly fast, I think that maybe it used some kind of legacy workaround without libdispatch and libblocksruntime.

I also don't have crushes now, so I'm getting to conclusion that your fast-srckit should be in sync with currently installed swift version I suppose, my version of swift is 5.2.4

[Lavmint]

upd: there is no deference with libs of without, it depend on imports. FoundationNetworking is fast Foundation is slow however I'm not getting any errors or crashes with original lsp

[Lavmint]

@haifengkao what branch of lsp does fast-lsp suppor/based on?

I can see 5.1.x, 5.2.x and 5.3 (current development) branches in original apple repo Your comment is at April 8th, swift 5.3 is tagged by march 24th.

So you are supporting upstream swift version 5.3? Maybe that's why I'm getting errors on 5.2 ?

[haifengkao]

I push all my changes to master branch. I do not touch any other branches. In fact, the changes are almost in this commit (https://github.com/haifengkao/fast-sourcekit-lsp/commit/3177e21234942ec7db4ed5bb96057700e33c86d1)

upd: there is no deference with libs of without, it depend on imports.
FoundationNetworking is fast
Foundation is slow

That's correct, because original sourcekit will return ALL symbols to vscode. If the header has a lot of symbols(> 10k), it will be very slow. All I did is removing the irrelevant symbols before sending them to vscode.