Unable to start LSP in Helix Editor

[bitcrshr]

Swift version

main-snapshot-2025-04-12

Platform

MacOS 15.0.1

Editor

Helix 25.01.1

Description

Hello!

I have been trying to get sourcekit-lsp to work properly with Helix for a few days, but I haven't been able to crack it. My main use case is embedded Swift with ESP-IDF. There are two scenarios:

1. No workspace folder in initialize request -> LSP mostly works, but does not pick up on C/C++ imports from BridgingHeader.h despite having compile_commmands.json
2. Workspace folder in initialize request -> LSP fails to start at all, getting this error: 2025-04-30T17:58:16.883 helix_lsp::transport [ERROR] sourcekit-lsp <- ServerError(-32001): sourcekitd request failed: error response (Request Failed): Loading the standard library failed

Note that the first scenario is possible because Helix won't consider an open folder a workspace unless it has a .git or .helix directory in it.

Seems that the VSCode extension works perfectly, but I wasn't able to find anything that stuck out while comparing the LSP messages to/from Helix vs VSCode.

Any guidance would be greatly appreciated! If this seems to be more of a Helix issue, I'd be happy to make an issue on their side and link here in case anyone else runs into this. I'm pretty new to Swift as well, so this may also simply be a skill issue.

Steps to Reproduce

The project I'm working on is here. It's a copy of swift-matter-examples/empty-template with minimal changes. I did add <driver/gpio.h> along with some others to BridgingHeader.h, which is needed for the gpio_num_t type in main/LightbarController.swift. I did also add set(CMAKE_EXPORT_COMPILE_COMMANDS, ON) to the root CMakeLists.txt as a sanity check.

Logging

sourcekit-lsp-diagnose-2025-04-30T18-09-51-04-00.zip

[ahoppen]

I think I remember an issue that Helix doesn’t forward environment variables from the system to the LSP server. In either case SourceKit-LSP seems to be picking up Xcode command line tools as the toolchain (search for Using toolchain at in the logs) and I assume that you want to use an open source toolchain. I suspect the presence of PATH is what makes this work in VS Code but not Helix.

I thought we had an issue somewhere that we should infer the toolchain from the compiler that’s mentioned din compile_commands.json but I can’t find that right now. Fixing that would be an alternative solution to the problem.

[ahoppen]

I just looked into this further and compile_commands.json does use the compiler mentioned in the compilation database if it is a toolchain that’s known to SourceKit-LSP. That leaves open the question: Why doesn’t SourceKit-LSP find the toolchain that you want to use. To help us figure that out, could you share the following details?

• The full path of the sourcekit-lsp executable that is being launched by Helix and the one launched by VS Code? ps -eE <PID> should give that information and also include any environment variables that are being set when launching sourcekit-lsp. You can find the PID of sourcekit-lsp using ps -A | grep "sourcekit-lsp " or in Activity Monitor.app
• One entry of your compile_commands.json (or the entire compile_commands.json if you don’t mind sharing it)

Thanks for your help to investigate this.

[bitcrshr]

Sure thing! I included these as files to save precious vertical space here, but lmk if you're more comfortable with plaintext.

Interesting that Helix uses /Library/Developer/CommandLineTools/usr/bin/sourcekit-lsp and VSC uses /Users/chandler/Library/Developer/Toolchains/swift-6.1-RELEASE.xctoolchain/usr/bin/sourcekit-lsp. Neither is using what Swiftly installed. I'm going to toy around a bit and see what I can come up with.

compile_commands.json

helix.txt

vscode.txt

[bitcrshr]

Update: Helix works beautifully with sourcekit-lsp on Linux, so I'm thinking this is due to a wonky system environment on my macbook, and not an issue with the lsp or helix.

[ahoppen]

Ah, looks like the issue is that you are using swift from swiftly (#2128). I just fixed this issue on main (#2143) and the fix should be in the next nightly toolchain once it’s released. I’m also cherry-picking the fix to 6.2 here: #2146