Can we vend standalone binary releases?
tinder-tannerbennett opened this issue · comments
I would like to use some recent fixes that are not in a final release of Xcode yet, but I don't want to install a 5 GB toolchain just to get an updated copy of sourcekit-lsp. I can always build it myself from source, but having releases makes the workflow surrounding updating this tool easier.
I want the standalone tool without a toolchain because I just want to use it with VS Code for code folding and such.
Tracked in Apple’s issue tracker as rdar://124787530
While it’s usually possible to use sourcekit-lsp with sourcekitd from an older (or newer for that matter) toolchain, and we do try to make it work as best as possible, mixing-and-matching them is not a supported configuration in general, so there are no plans to provide prebuilt binaries of sourcekit-lsp.
Out of curiosity: What are the features from newer sourcekit-lsp that you would like to use? Rename, for example, requires a new version of sourcekitd as well.
I did not realize a separate sourcekitd process was required as well! Yikes. Does that mean you can't use two different instances of the language server at the same time? I.E. if I'm using the default one in Xcode and a downloaded toolchain in VS Code?
I mainly just wanted some minor bug fixes for use with VS Code. The last release has a lot of code folding issues that I run into all the time that have been since fixed but not yet released with Xcode.
What do you mean by having two different language servers at the same time? In general you should be using sourcekitd and sourcekit-lsp from the same toolchain that you use to build the project. If you use a different sourcekitd version (most likely because you eg. build using Xcode’s toolchain but then use sourcekit-lsp from eg. an open source toolchain), it won’t be able to read the .swiftmodule files you created during the build, which will cause most functionality that needs some kind of cross-module behavior (diagnostics, code completion, jump-to-definition, …) to fail.
If you use a different version of sourcekit-lsp but point it to a toolchain/sourcekitd, most things will likely continue to work and you will get fixes from behavior that is performed inside sourcekit-lsp and doesn’t delegate to sourcekitd. This includes most syntactic behavior (like code folding). You can get a rough idea of what behavior might break in such a configuration by looking at https://github.com/apple/sourcekit-lsp/blob/main/Sources/SKTestSupport/SkipUnless.swift. The biggest problem that you’ll encounter here is most likely that SwiftPM moved the generated .swiftmodules between (I think) Swift 5.10 and 6.0 into a Modules subdirectory of your build folder. Because of this, sourcekit-lsp won’t find you .swiftmodules and you’re in the situation described above.
So, to summarize: It’s fine to build sourckit-lsp yourself and use it with an older toolchain but if things don’t work in that configuration, that’s not considered a bug on our side. I would encourage you to use a Swift development snapshot.
What do you mean by having two different language servers at the same time?
While running VS Code using the Swift extension, and while running Xcode. I installed one of the newer toolchains and copied the language server binary out and into my PATH and pointed VS Code to it.
If you use a different version of sourcekit-lsp but point it to a toolchain/sourcekitd, most things will likely continue to work and you will get fixes from behavior that is performed inside sourcekit-lsp and doesn’t delegate to sourcekitd
Awesome 🙏🏻 That's the sort of thing I want a release for, so I don't have to go through the hassle of installing the toolchain, copying the LSP binary, and uninstalling the toolchain. I realize this is probably an uncommon use case though
While running VS Code using the Swift extension, and while running Xcode. I installed one of the newer toolchains and copied the language server binary out and into my
PATHand pointed VS Code to it.
Xcode doesn’t actually use sourcekit-lsp, it does use sourcekitd though. Also, since Xcode usually stores builds in DerivedData and SwiftPM builds in .build, Xcode and VS Code probably won’t interfere and you should be able to use them side-by-side (VS Code can build with a newer toolchain into .build while Xcode continues building with its own toolchain in DerivedData).
Awesome 🙏🏻 That's the sort of thing I want a release for, so I don't have to go through the hassle of installing the toolchain, copying the LSP binary, and uninstalling the toolchain. I realize this is probably an uncommon use case though
The problem is that with a standalone release of sourcekit-lsp we would be suggesting that sourcekit-lsp can be updated independently, which isn’t true in general.