Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to configure extension on NixOS #988

Open
thomaseizinger opened this issue Jul 30, 2024 · 10 comments
Open

Unable to configure extension on NixOS #988

thomaseizinger opened this issue Jul 30, 2024 · 10 comments
Labels
bug Something isn't working

Comments

@thomaseizinger
Copy link

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.

@thomaseizinger thomaseizinger added the bug Something isn't working label Jul 30, 2024
@adam-fowler
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

lokesh-tr commented Jul 31, 2024

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
Copy link
Author

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.

@adam-fowler
Copy link
Contributor

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

@thomaseizinger
Copy link
Author

@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
Copy link
Author

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 thomaseizinger reopened this Aug 3, 2024
@thomaseizinger
Copy link
Author

That seems to be a known issue already tracked in swiftlang/swift#67975.

@adam-fowler
Copy link
Contributor

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
Copy link
Author

Not sure this is something the VSCode extension can fix.

I opened an issue on nixpkgs too: NixOS/nixpkgs#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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants