Can sourcekit-lsp provide a LSP service for cross-compiled code?

[LebJe (Jeff L)]

Dear Swift Community,

Xcode can cross-compile applications to WatchOS/tvOS/iOS/iPadOS, and provide code completion for frameworks/libraries only available on those platforms using sourcekit. Can sourcekit-lsp use Swift cross-compilation toolchains* to provide code completion for those toolchain's compilation target, e.g. x86_64-unknown-linux-gnu?

* SwiftCrossCompilers and SPMDestinations.

Jeff

[blangmuir (Ben Langmuir)]

I'm not familiar with those particular projects. A few general comments:

• In principle the sourcekit-lsp that is included in a given Swift toolchain should be able to support all of the same targets that the compiler and swiftpm can support. We use the same underlying technology.
• That being said, this isn't specifically being tested so there may be gaps, particularly around configuration. For example, we expose a few swiftpm-style options like -Xswiftc in sourcekit-lsp, but we may be missing something that is important for cross-compilation use-cases.
• We would generally be open to contributions to bring sourcekit-lsp in line with swiftpm if there are scenarios that work in swiftpm but not sourcekit-lsp.

[LebJe (Jeff L)]

@blangmuir

I'm not familiar with those particular projects.

Cross-compilation is achieved using:

$ swift build --destination /path/to/destination.json

The destination.json is available in the cross-compilation toolchain.

Can sourcekit-lsp support SwiftPM build flags like --destination or --static-swift-stdlib?

[blangmuir (Ben Langmuir)]

We do not currently support the --destination option in sourcekit-lsp. @Max_Desiatov looked at adding it a while ago, but I don't recall what specific issues he ran into.

I wouldn't expect --static-swift-stdlib to matter for sourcekit-lsp since we're not going to link the code.

[LebJe (Jeff L)]

Ten months later…

@blangmuir

I wouldn't expect --static-swift-stdlib to matter for sourcekit-lsp since we're not going to link the code.

Whoops, I had meant to use that flag as an example, like you said it wouldn’t make much sense here.

@blangmuir

We would generally be open to contributions to bring sourcekit-lsp in line with swiftpm if there are scenarios that work in swiftpm but not sourcekit-lsp.

I’m currently experimenting with adding support for a --product option (like swift build) that would tell SourceKit-LSP to only provide a service for the specified product in a Swift package. Would a PR adding this feature be accepted?

@blangmuir

We do not currently support the --destination option in sourcekit-lsp. @Max_Desiatov looked at adding it a while ago, but I don't recall what specific issues he ran into.

I found the PR and will see if it can work with a cross-compilation toolchain like SwiftCrossCompilers.

Jeff

[blangmuir (Ben Langmuir)]

@LebJe

I’m currently experimenting with adding support for a --product option (like swift build ) that would tell SourceKit-LSP to only provide a service for the specified product in a Swift package. Would a PR adding this feature be accepted?

Is this for performance to avoid computing settings for all targets, or is something going wrong if you include all the products that prevents you from working with the files that you do care about?

[LebJe (Jeff L)]

I’m working on a package that can’t be built using swift build because some products are meant for another platform, but when SourceKit-LSP loads a package, it is doing the equivalent of calling swift build.
I’ve added explicitProduct: <product> to self.workspace.loadPackageGraph in my local SourceKit-LSP to fix this.

[blangmuir (Ben Langmuir)]

@LebJe

when SourceKit-LSP loads a package, it is doing the equivalent of calling swift build .

We don't build code, we try to configure code and get its build settings. Are you saying that is failing? It would be nice if we could either fix swiftpm to not fail to give us settings, or make sourcekit-lsp and/or swiftpm more resilient so we can still get settings for the subset of the project that will work.