SourceKit-LSP on Windows?

Maybe specifically addressed to @compnerd, what is the status of SourceKit and its server implementation on windows? So far I couldn't find any topic here about its usage on this platform and the integration page ( https://github.com/apple/sourcekit-lsp/blob/master/Editors/README.md ) doesn't even mention the toolchain on windows (which is weird because the sourcekitd-test works fine so I'm assuming there must be something available there)

I do not use a LSP implementation in my day-to-day development, so I'm not as familiar with it as someone who uses it daily would be. I know that it has been possible to build it in the past, though that has regressed some. I've uploaded (nearly?) all of my local patches that enable building it, but I know that there is still work to be done to make SourceKit-LSP work on Windows. As an example of one of those necessary changes: clang must be replaced with clang.exe and similarly for swiftc.

The recent work on swift-package-manager should make supporting SourceKit-LSP on Windows significantly easier now though as it should be able to use that to get the flags that it needs to index the codebase.

A note on building if you are planning on trying to build SourceKit-LSP: I've had trouble building SourceKit-LSP with both swift-package-manager and CMake. The changes for the latter are on GitHub as PRs now in their respective repositories. The former, I am still trying to puzzle out, but I suspect that I have something wrong. I saw issues with swift-argument-parser resolution since there is a version mismatch (0.3.1 vs 0.3.0), and working through that uncovered another issue where there are incompatible builds of LLVMSupport that tried to get linked into the SourceKit executable failing the build. Figuring out the latter should actually make it much eaier to debug since you would then be able to use lldb on the SourceKit-LSP server process.

EDIT: apple/swift-package-manager#2912 should :crossed_fingers: fix the first of the two issues with building with swift-package-manager.

Hey @compnerd thanks for taking the time to reply.
Leaving the LSP implementation aside, what about SourceKit in general? Are there any binaries for sourcekitd in the toolchains?

Hello, and of course, you're welcome.

Sorry, I missed the first part of the question and only answered the second part about the LSP implementation. I don't know of any known issues with SourceKit on Windows (though that doesn't mean that there aren't any), and the CI should be building and testing it as well. I don't know about executables for SourceKit, but the library for SouceKit should be part of the build (sourcekitdInProc.dll). As you mentioned - sourcekitd-test works and that is used as part of the test suite. Personal wishful thinking on my part - I would like to see an out-of-proc SourceKit server using COM on Windows, but that doesn't seem like a blocker to the use of SourceKit currently.

The LSP implementation would be the more interesting aspect I think because it should stress test the implementation and help flush out issues that may have been missed.

2 Likes

Unfortunately, the Swift toolchain for Windows does not include the binary for sourcekit-lsp, which means none of the editors work correctly on Windows.

By default, the swift toolchain is installed in the following PATH which does not have the sourcekit-lsp binary

C:\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin

I maintain Atom's package for sourcekit, but not having Windows support is not desirable.

Hi @aminya

I'm also experimenting with Windows. I'm running the 24/10 snapshot and that does include sourcekit-lsp on the PATH. I could install the VS Code extension just like I did on Linux (with no configuration required), and it seems to work fine (although @compnerd said it still has issues).

PS: Instructions for Atom as an editor are more than welcome!

1 Like
Terms of Service

Privacy Policy

Cookie Policy