Moving a project results in "Internal SourceKit error: Loading the standard library failed"

Using Swift
1

I’ve been trying out Nova with SourceKit-LSP (via the official Icarus extension) for the past week or so. It’s mostly been fine, but today I’m getting an error: Internal SourceKit error: error response (Request Failed): Loading the standard library failed.

Why would this happen with no apparent changes to my environment, and is there a way I can debug this further?

Edit: apparently I broke things when I moved my project under a Sources directory:

[0/1] Planning build
Building for debugging...
[0/2] Write sources
[1/2] Write swift-version--58304C5D6DBC2206.txt
error: emit-module command failed with exit code 1 (use -v to see invocation)
[3/8] Compiling «project-name» «source-file».swift
<unknown>:0: error: PCH was compiled with module cache path '/Users/Kyle/«project-name»/.build/arm64-apple-macosx/debug/ModuleCache/16QR8I3BU9Y6T', but the path is currently '/Users/kyle/Source/«project-name»/.build/arm64-apple-macosx/debug/ModuleCache/16QR8I3BU9Y6T'
  1. Are PCH files really not relocatable?
  2. Does LSP allow SourceKit to be more informative with this diagnosis?
2

PCH/PCM files are extremely non-relocatable in general, especially when using the implicit module cache, since they're just meant to be transient artifacts. Explicit modules can be made relocatable through some Clang flags (and I believe SwiftPM can use explicit modules in its new build planning logic) but there are still issues where SourceKit-LSP can't use the same explicit modules that the compiler uses so that's probably where the implicit module cache is coming from.

Deleting the ModuleCache directory ought to be enough to get things working again. If not, delete any *.pch/*.pcm files that might be lurking in your build outputs.

I don't remember the exact flow that the errors take through SourceKit but I've often found that "loading the standard library failed" is usually a red herring that points to something else going wrong and it's just the fallback error. Like in your case, ClangImporter is failing when it tries to load the modules into an instance that's no longer compatible. I do think it would be nice to propagate the actual errors up, if possible.

3

The better resolution would probably be for SourceKit-LSP or SwiftPM to delete these pcms and just re-generate them or at least give you an indication what’s going wrong. Could you file an issue for this in GitHub - swiftlang/sourcekit-lsp: Language Server Protocol implementation for Swift and C-based languages?