SourceKitLSP: fallback to Swift source for SDK symbol resolve#2664
SourceKitLSP: fallback to Swift source for SDK symbol resolve#2664compnerd wants to merge 1 commit into
Conversation
When resolving a workspace symbol whose location points at an SDK .swiftmodule/.swiftinterface, SourceKit-LSP currently asks IndexStoreDB for main files containing that module file and uses one of those files to provide build settings for opening the generated interface. That relationship is not guaranteed to exist for SDK module files. The module file can appear as the indexed symbol location, while mainFiles(containing:) still returns no source file. This causes workspaceSymbol/resolve to fail before calling sourcekitd, with errors like: No source file found that imports Swift.String; cannot open generated interface If no main file is found for the module file, fall back to a buildable Swift source file from the workspace. The file is only used as the source of compiler arguments for generating the interface, so any buildable Swift source in the workspace is sufficient. This fixes resolving stdlib/SDK workspace symbols such as Swift.String on Windows SDK layouts where the stdlib location is a .swiftmodule under the SDK.
|
@swift-ci please test |
Not always. Some build server can support multiple targets for different platforms. IMO, the right fix is, when no workspace doesn't have a main file for it, use How?
|
|
If this is blocking something for Windows, feel free to disable it for Windows for now. |
|
The current desire is for testing, but it seems that the test suite passed on CI, so I can hold off on this until someone has time to look into your recommendation |
| .sorted(by: { $0.arbitrarySchemeURL.absoluteString < $1.arbitrarySchemeURL.absoluteString }) | ||
| } ?? [] | ||
| } | ||
| let mainFile = candidateMainFiles.first |
There was a problem hiding this comment.
That doesn’t seem correct. A project may contain some files that are built for eg. the iOS SDK while others that are built for the watchOS SDK and you can’t open a module from the iOS SDK with build settings from the watchOS SDK.
What’s the exact issue that you’re seeing here? Do you have a test case that reproduces it?
3 participants
When resolving a workspace symbol whose location points at an SDK .swiftmodule/.swiftinterface, SourceKit-LSP currently asks IndexStoreDB for main files containing that module file and uses one of those files to provide build settings for opening the generated interface.
That relationship is not guaranteed to exist for SDK module files. The module file can appear as the indexed symbol location, while mainFiles(containing:) still returns no source file. This causes workspaceSymbol/resolve to fail before calling sourcekitd, with errors like:
No source file found that imports Swift.String; cannot open generated interface
If no main file is found for the module file, fall back to a buildable Swift source file from the workspace. The file is only used as the source of compiler arguments for generating the interface, so any buildable Swift source in the workspace is sufficient.
This fixes resolving stdlib/SDK workspace symbols such as Swift.String on Windows SDK layouts where the stdlib location is a .swiftmodule under the SDK.