VSCode swift getting really flaky again on recent toolchain snapshots

taylorswift · November 12, 2022, 10:47pm

over the past month i’ve been running into more and more issues with the VSCode swift extension (after some improvement during the month of october):

imported modules are randomly unavailable and generate LSP errors, even though the package builds successfully with swift build
imported modules are randomly unavailable, and do not generate LSP errors, but cause large swaths of code within a file to lose syntax/semantic highlighting because they contain a reference to something in that module
the above two problems sometimes occur across files in the same module (that import the same dependency).
explicitly building the target with swift build --target, which used to resolve most of the above problems, is no longer effective
semantic highlighting no longer degrades gracefully when any of the above conditions occurs, instead everything that is not a keyword becomes an identifier. (every type name becomes an identifier.) this is a different problem than when sourcekit-lsp crashes entirely (the “everything becomes a comment” problem).

these problems are hard to reproduce in small projects, they only show up in large projects, so i’m at a loss as to what’s causing them, because the package compiles fine.

has anyone else experienced anything similar recently?

taylorswift · November 13, 2022, 6:34pm

update: did some more digging this morning, and it looks like multi-module use cases are completely broken, as i could not get VSCode working with even a minimal two-module setup.

i filed a sourcekit-lsp issue here:

github.com/apple/sourcekit-lsp

multi-module use cases are completely broken: could not open compilation database

opened 06:30PM - 13 Nov 22 UTC

kelvin13

multi-module use cases appear to be completely broken. if i have a module named …`A` with example code: ```swift // A.swift public enum A { struct Foo { } } extension A.Foo { func test(x _:Int) { } } ``` i get normal highlighting and LSP features, though it emits an error to the console: ``` 2022-11-13 18:22:26.497 sourcekit-lsp[393:402dc700] could not open compilation database for /example/Sources/A/A.swift ``` if i go to another module that imports `A`, sourcekit-lsp doesn’t seem to work at all. ```swift // B.swift import A extension A { struct Bar { } } extension A.Bar { func test(x _:Int) { } } ``` it also emits a similar error to the console: ``` 2022-11-13 18:27:00.923 sourcekit-lsp[393:402dc700] could not open compilation database for /example/Sources/B/B.swift ``` but because it also emits the same error in `A.swift`, i am not sure if the error is related to this issue. here is a full example project, including a `.devcontainer` directory for reproduction: [vscode-example.zip](https://github.com/apple/sourcekit-lsp/files/9997962/vscode-example.zip) the specific toolchain i am using currently is `swift-DEVELOPMENT-SNAPSHOT-2022-11-11-a`, but the problem has been going on for most of november.

taylorswift · November 13, 2022, 7:09pm

after even more fiddling around, i have found (very anecdotally) that VSCode swift really struggles with .devcontainer being in the same directory as a Package.swift. this is probably why swift package edit does not get along with VSCode swift, but it also seems to affect shallow packages that just have a .devcontainer directory that is a sibling of the Package.swift.

to work around this issue, you need to nest your swift project directory inside a parent directory that is mounted by the docker container, and contains the .devcontainer. and do not use swift package edit. i verified this works with the november toolchains.

sourcekit-lsp still cannot seem to build dependencies automatically, but can still trigger the builds manually with swift build --target.

hope this helps anyone else experiencing this problem!

adam-fowler · November 14, 2022, 8:25am

Given you are mentioning the .devcontainer folder I assume you are running inside a dev container. It appears you are using one of the latest development builds of swift. Are you getting similar issues with swift 5.7.1?

taylorswift · November 14, 2022, 7:45pm

no, thankfully the swift 5.7.1 toolchain is much more stable, and i would be using it were it not for changes in the swift-syntax library that require me to use a specific nightly snapshot.

i probably should have clarified when i was referring to the october/november toolchains i was referring to the DEVELOPMENT-SNAPSHOT builds.