Unable to configure extension on NixOS

[thomaseizinger]

Describe the bug

I am trying to configure this extension in NixOS. I am setting swift.path to a directory that has two symlinks:

• swift to the swift binary
• sourcekit-lsp to the sourcekit-lsp binary

❯ ls -la /nix/store/kqv3ydcl2awcsgirb85dz3ab4amd1f00-swift-vscode-env/bin
lrwxrwxrwx - root  1 Jan  1970 sourcekit-lsp -> /nix/store/kzfcyfl7s82744xhhh1j4gwlhyn0ihwn-sourcekit-lsp-5.8/bin/sourcekit-lsp
lrwxrwxrwx - root  1 Jan  1970 swift -> /nix/store/jlpi1wiiqknd9jdqlwvi330j89wjy6b4-swift-wrapper-5.8/bin/swift

Despite these things being in place, the extension tries to start the sourcekit-lsp binary from the wrong directory:

[Error - 15:19:02] SourceKit Language Server client: couldn't create connection to server.
Launching server using command /nix/store/jlpi1wiiqknd9jdqlwvi330j89wjy6b4-swift-wrapper-5.8/bin/sourcekit-lsp failed. Error: spawn /nix/store/jlpi1wiiqknd9jdqlwvi330j89wjy6b4-swift-wrapper-5.8/bin/sourcekit-lsp ENOENT

If I remove the symlink, the extension correctly starts the LSP server but it then complains that it cannot find swift (understandably).

To Reproduce

See above.

Expected behavior

To respect the configured symlinks.

Environment

• OS: NixOS 24.11
• Swift version: 5.8
• Visual Studio Code version: 1.90.1
• vscode-swift version: 1.10.2

Additional context

It is somewhat inconvenient that the configuration for sourcekit-lsp and swift is just one directory. Other LSPs that I use allow you to configure a direct path to the LSP binary. That seems to be more robust as I've not run into any issues with Rust and Kotlin for example.

[adam-fowler]

Is the swift toolchain on NixOS structured differently from the standard toolchains? The extension is assuming the Swift executable is part of a toolchain, which includes lldb, swiftc, sourcekit-lsp and various other binaries.

You can also set the path to the sourcekit-lsp executable in the settings.

[thomaseizinger]

Is the swift toolchain on NixOS structured differently from the standard toolchains? The extension is assuming the Swift executable is part of a toolchain, which includes lldb, swiftc, sourcekit-lsp and various other binaries.

swiftc and sourcekit-lsp are in different packages, yes.

You can also set the path to the sourcekit-lsp executable in the settings.

Which setting is that? I can only find one to set a path to the entire Swift SDK with swiftc etc. (swift.path).

[lokesh-tr]

Which setting is that? I can only find one to set a path to the entire Swift SDK with swiftc etc. (swift.path).

"swift.sourcekit-lsp.serverPath": "/path/to/sourcekit-lsp"

See if this solves your issue 🙂

It is somewhat inconvenient that the configuration for sourcekit-lsp and swift is just one directory. Other LSPs that I use allow you to configure a direct path to the LSP binary. That seems to be more robust as I've not run into any issues with Rust and Kotlin for example.

For context: This setting will only work if the swift toolchain used to produce the sourcekit-lsp executable and the swift toolchain which you configure are the same. The sourcekit-lsp which comes from official swift releases are produced using the corresponding swift toolchain from the release. So, this might solve your issue.

This setting won't show up in the settings UI because its very easy to mess up the settings configuration since having mismatching sourcekit-lsp and swift can lead to unexpected behaviour . Its only encouraged to use this setting if you know very well that the swift and sourcekit-lsp toolchain matches (which should be the case for official releases)

[thomaseizinger]

Thanks! That part seems to work. It is now complaining that it can't find certain packages and that the manifest is invalid :upside_down_face:

But at least it starts.

[adam-fowler]

@thomaseizinger out of interest where is the swift version of lldb stored in a NixOS install of Swift.

[thomaseizinger]

@thomaseizinger out of interest where is the swift version of lldb stored in a NixOS install of Swift.

They are in the same directory:

❯ ls -la /nix/store/h8gh9cg2z137ql7h1bgnhr9ixwcwj4az-swift-5.8/bin
lrwxrwxrwx    - root  1 Jan  1970 clang -> clang-15
.r-xr-xr-x 119M root  1 Jan  1970 clang-15
.r-xr-xr-x 255k root  1 Jan  1970 lldb
.r-xr-xr-x  81k root  1 Jan  1970 lldb-argdumper
.r-xr-xr-x  67M root  1 Jan  1970 lldb-instr
.r-xr-xr-x 110M root  1 Jan  1970 lldb-server
.r-xr-xr-x 514k root  1 Jan  1970 lldb-vscode
.r-xr-xr-x  16k root  1 Jan  1970 repl_swift
dr-xr-xr-x    - root  1 Jan  1970 sdk-module-lists
lrwxrwxrwx    - root  1 Jan  1970 swift -> swift-frontend
.r-xr-xr-x  12k root  1 Jan  1970 swift-api-checker.py
lrwxrwxrwx    - root  1 Jan  1970 swift-api-digester -> swift-frontend
lrwxrwxrwx    - root  1 Jan  1970 swift-api-extract -> swift-frontend
lrwxrwxrwx    - root  1 Jan  1970 swift-autolink-extract -> swift-frontend
.r-xr-xr-x 1.6M root  1 Jan  1970 swift-demangle
.r-xr-xr-x 140M root  1 Jan  1970 swift-frontend
lrwxrwxrwx    - root  1 Jan  1970 swift-indent -> swift-frontend
lrwxrwxrwx    - root  1 Jan  1970 swift-symbolgraph-extract -> swift-frontend
lrwxrwxrwx    - root  1 Jan  1970 swiftc -> swift-frontend

[thomaseizinger]

Thanks! That part seems to work. It is now complaining that it can't find certain packages and that the manifest is invalid 🙃

But at least it starts.

Actually, I need to retract that. It crashes with the following message:

2024-08-03 18:01:29.517 sourcekit-lsp[56787:c4a006c0] failed to start language service open("/nix/store/h8gh9cg2z137ql7h1bgnhr9ixwcwj4az-swift-5.8/lib/libsourcekitdInProc.so: undefined symbol: _Z13OStream_write14BridgedOStreamN4llvm9StringRefE")

[thomaseizinger]

That seems to be a known issue already tracked in https://github.com/swiftlang/swift/issues/67975.

[adam-fowler]

Not sure this is something the VSCode extension can fix. It seems odd that NixOS have decided to release these as separate packages. The version of sourcekit-lsp is very closely linked to the Swift version.

Is there any chance you have a different version of sourcekit-lsp from Swift? Also can you run sourcekit-lsp separately from VSCode?

[thomaseizinger]

Not sure this is something the VSCode extension can fix.

I opened an issue on nixpkgs too: https://github.com/NixOS/nixpkgs/issues/331943

It seems odd that NixOS have decided to release these as separate packages. The version of sourcekit-lsp is very closely linked to the Swift version.

I'll raise it with the maintainers.

Is there any chance you have a different version of sourcekit-lsp from Swift?

Both packages say version 5.8.

Also can you run sourcekit-lsp separately from VSCode?

Yes. I am getting:

❯ ./sourcekit-lsp
2024-08-03 18:22:00.465 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.465 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.465 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.466 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.466 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.467 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.468 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.468 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.469 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.469 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension
2024-08-03 18:22:00.470 sourcekit-lsp[60751:97e006c0] Could not determine host OS. Falling back to using '.so' as dynamic library extension