Wants to support setting destination file, which can help sourcekit-lsp searching correct target symbol index.

[CmST0us]

Like this issues #552

I want to proposal an other way, or say it just for soucekit-lsp. Let vscode-swift support read destination file, and can set target. Then vscode-swift can read the destination file and target setting, to build sourcekit-lsp argument. https://github.com/swift-server/vscode-swift/blob/32e1d8f2957c8b32164a2da69b7f674909251255/src/sourcekit-lsp/LanguageClientManager.ts#L80

https://github.com/swift-server/vscode-swift/blob/32e1d8f2957c8b32164a2da69b7f674909251255/src/toolchain/BuildFlags.ts#L115

For example, I have an destination file https://github.com/CmST0us/armhf-swift-toolchain/blob/main/Destinations/macos/arm-none-linux-gnueabihf-5.9.json

And I can read it in vscode-swift, so I will know the sourcekit-lsp -Xcc -Xswiftc -Xcxx argument and --scratch-path argument. Then vscode-swift can use this argument to communicate to sourcekit-lsp server.

Why I call this way JUST FOR sourcekit-lsp? because I can use destination file to cross-compile, but i find it hard to write code. In default, if you use vscode-swift in x86_64 linux platform, vscode-swift will use x86_64 linux target to index and store symbol, and it works good. So if you want to write code for aarch64 linux platform, symbol searching will be ugly.

Relate: https://github.com/apple/swift-package-manager/issues/6699

[adam-fowler]

I was going to do this but the new SDK support appears to usurp the destination files, so I thought I'd wait until that was fully implemented.

You need to build the package with the same arguments as you send to sourcekit-lsp, otherwise the index store will not be updated with correct values.

[CmST0us]

Thank you for your reply. I will temporarily try using VSCode Remote for remote coding. I'm very much looking forward to your progress.