LSP integration with CMake and nightly toolchains

Using Swift
41

@Lua, the thread title here really is pretty needlessly inflammatory. I'll change it in a few hours if you don't handle it first.

1 Like
42

I agree, sorry about that, I think I was upset when writing that.

43

No worries, thanks for taking care of it.

44

Sorry you've been having a tough time here @Lua, thanks for submitting the compiler issue and putting up your repo.

In general, sourcekit-lsp supports Swift packages, compile_commands.json/compile_flags.txt, and custom BSP servers. The 6.1 nightlies have background indexing enabled by default for Swift packages and BSP servers (if it contains our extensions), but for compilation databases a build is still required to update the index and Swift modules. So in the case of BlockGameSwift, that would mean you need to run a build in order to see Core changes within Engine (or more generally, to have jump to definition/completion/etc for Core within Engine).

We do have docs for setting up some editors, though Zed is not in that list. From a brief look at its source, it appears to search $PATH first and then xcrun as a fallback, so I wouldn't expect too much to be needed there - creating an issue with a diagnostic bundle would help us track down whether it's an issue on our (sourcekit-lsp) end or the extension.

I did give BlockGameSwift a quick try in VS Code with compile_commands.json on the latest nightly and hit some snags which I'll put up issues for next week:

  1. defaultWorkspaceType in the workspace config.json is not respected
  2. Relative paths within a command are not resolved by sourcekitd
  3. Certain diagnostics are erroneously output in embedded Swift as sourcekitd disables WMO (cannot_specialize_class is the one I'm seeing in Main.swift, but there could be others)

After moving Package.swift aside, building, and fixing up the relative paths in compile_commands.json, semantic functionally all worked (where I tried) except for the erroneous diagnostics (3). Though I should note I preemptively commented out the crashing copy (since that prevented a debug build for me).

4 Likes
45 
Undefined symbols for architecture arm64:
  "__swift_stdlib_getComposition", referenced from:
      Swift.Unicode._NFCNormalizer._resume(consumingNFD: (inout Swift.Unicode._NFCNormalizer) -> (scalar: Swift.Unicode.Scalar, normData: Swift.Unicode._NormData)?) -> Swift.Unicode.Scalar? in Application.swift.o
      Swift.Unicode._NFCNormalizer._resume(consumingNFD: (inout Swift.Unicode._NFCNormalizer) -> (scalar: Swift.Unicode.Scalar, normData: Swift.Unicode._NormData)?) -> Swift.Unicode.Scalar? in Application.swift.o
  "__swift_stdlib_getDecompositionEntry", referenced from:
      Swift.Unicode._NFDNormalizer.(decomposeSlow in _B136021ACF5AAEFA178D70CE67C7EEF0)((scalar: Swift.Unicode.Scalar, normData: Swift.Unicode._NormData)) -> () in Application.swift.o

I understand SDL, I didn't configure linking it, but what is unicode doing there? It seems to be working fine with Cmake

This part ("why am I getting linker errors about Unicode stuff") is described here: swift/docs/EmbeddedSwift/UserManual.md at main · swiftlang/swift · GitHub

Basically, we assume Embedded Swift users care a lot about their binary sizes, so they need to manually link the (relatively large) unicode data tables to acknowledge that they actually expect those in their resulting binaries.

2 Likes
46

That much I know, but what confuses me is that it seems to work by default with CMake, and also trying to link the library in the Package.swift linkerSettings for Core caused the opposite problem, all the symbols got defined multiple times.