SourceKit-LSP is an implementation of the Language Server Protocol (LSP) for Swift and C-based languages. It provides features like code-completion and jump-to-definition to editors that support LSP. SourceKit-LSP is built on top of sourcekitd and clangd for high-fidelity language support, and provides a powerful source code index as well as cross-language support. SourceKit-LSP supports projects that use the Swift Package Manager.
SourceKit-LSP is under heavy development! The best way to try it out is to build it from source. You will also need a Swift development toolchain and an editor that supports LSP.
Install the latest master toolchain snapshot from https://swift.org/download/#snapshots. Set the environment variable
SOURCEKIT_TOOLCHAIN_PATHto the absolute path to the toolchain or otherwise configure your editor to use this toolchain. See Toolchains for more information.
Build the language server executable
swift build. See Building for more information.
Configure your editor to use the newly built
sourcekit-lspexecutable. See Editors for more information about editor integration.
Build the project you are editing with
swift build. The language server depends on the build to provide module dependencies and to update the global index.
SourceKit-LSP is built using the Swift Package Manager.
For a standard debug build:
$ swift package update $ swift build
After building, the server will be located at
.build/debug/sourcekit-lsp, or a similar path, if you passed any custom options to
swift build. Editors will generally need to be provided with this path in order to run the newly built server - see Editors for more information about configuration.
SourceKit-LSP is designed to build against the latest SwiftPM, so if you run into any issue make sure you have the most up-to-date dependencies by running
swift package update.
Building on Linux
The C++ code in the index requires
libdispatch, but unlike Swift code, it cannot find it automatically on Linux. You can work around this by adding a search path manually.
$ swift build -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift -Xcxx -I<path_to_swift_toolchain>/usr/lib/swift/Block
Using the Generated Xcode Project
If you would like to use the Xcode project generated by
swift package generate-xcodeproj, you will need to include the xcconfig overrides to avoid a link error.
$ swift package generate-xcodeproj --xcconfig-overrides overrides.xcconfig $ open SourceKitLSP.xcodeproj
You can attach LLDB to SourceKit-LSP and set breakpoints to debug. You may want to instruct LLDB to wait for the sourcekit-lsp process to launch and then start your editor, which will typically launch SourceKit-LSP as soon as you open a Swift file:
$ lldb -w -n sourcekit-lsp
If you are using the Xcode project, go to Debug, Attach to Process by PID or Name.
Print SourceKit Logs
You can configure SourceKit-LSP to print log information from SourceKit to stderr by setting the following environment variable:
Where "N" configures the log verbosity and is one of the following numbers: 0 (error), 1 (warning), 2 (info), or 3 (debug).
SourceKit-LSP depends on tools such as
clangd, which it loads at runtime from an installed toolchain.
Use the latest master toolchain snapshot from https://swift.org/download/#snapshots. SourceKit-LSP is still early in its development and we are actively adding functionality to the toolchain to support it.
Selecting the Toolchain
After installing the toolchain, SourceKit-LSP needs to know the path to the toolchain.
On macOS, the toolchain is installed in
.xctoolchainextension. The most recently installed toolchain is symlinked as
/Library/Developer/Toolchains/swift-latest.xctoolchain. If you opted to install for the current user only in the installer, the same paths will be under the home directory, e.g.
On Linux, the toolchain is wherever the snapshot's
.tar.gzfile was extracted.
Your editor may have a way to configure the toolchain path directly via a configuration setting, or it may allow you to override the process environment variables used when launching
sourcekit-lsp. See Editors for more information.
Otherwise, the simplest way to configure the toolchain is to set the following environment variable to the absolute path of the toolchain.
Indexing While Building
SourceKit-LSP uses a global index called IndexStoreDB to provide features that cross file or module boundaries, such as jump-to-definition or find-references. To efficiently create an index of your source code we use a technique called "indexing while building". When the project is compiled for debugging using
swift build, the compiler (swiftc or clang) automatically produces additional raw index data that is read by our indexer. Producing this information during compilation saves work and ensures that any time the project is built the index is updated and fully accurate.
In the future we intend to also provide automatic background indexing so that we can update the index in between builds or to include code that's not always built like unit tests. In the meantime, building your project should bring our index up to date.
SourceKit-LSP is still in early development, so you may run into rough edges with any of the features. The following table shows the status of various features when using the Recommended Toolchain. See Caveats for important known issues you may run into.
| Feature | Status | Notes |
| Swift | ✅ | |
| C/C++/ObjC | ❌ | As of
swift-DEVELOPMENT-SNAPSHOT-2019-02-14-a clangd is available but hitting frequent assertion failures.
| Code completion | ✅ | |
| Quick Help (Hover) | ✅ | |
| Diagnostics | ✅ | |
| Fix-its | ❌ | |
| Jump to Definition | ✅ | |
| Find References | ✅ | |
| Background Indexing | ❌ | Build project to update the index using Indexing While Building |
| Workspace Symbols | ❌ | |
| Refactoring | ❌ | |
| Formatting | ❌ | |
| Folding | ✅ | |
| Syntax Highlighting | ❌ | Not currently part of LSP. |
| Document Symbols | ✅ | |
SwiftPM build settings are not updated automatically after files are added/removed.
- Workaround: close and reopen the project after adding/removing files
SourceKit-LSP does not update its global index in the background, but instead relies on indexing-while-building to provide data. This only affects global queries like find-references and jump-to-definition.
- Workaround: build the project to update the index