All other types that conform to `BuildSystem` (which in sourcekit-lsp terms is something that can provide compiler arguments) had the `BuildSystem` suffix. `SwiftPMWorkspace` was an oddity here and was easily confused with the `Workspace` term in LSP, which essentially represents a single root folder that is being opened.
The naming was quite inconsistent here. Let’s rename these to `LanguageService` to highlight that they belong together.
- ToolchainLanguageServer -> LanguageService
- SwiftLanguageServer -> SwiftLanguageService
- ClangLanguageServerShim -> ClangLanguageService
The client ID was needed when a `MessageHandler` could handle messages from multiple connections. We don’t support this anymore (because it wasn’t needed) and so the client ID doesn’t need to get passed through as well.
I thought there was an issue with opening nested SwiftPM workspaces. Turns out there wasn’t but some logging and a test case don’t hurt.
rdar://124727086
If the `SourceKitServer` doesn’t have any other references anymore the LSP client is shutting down and there’s no point status updates from package reloading anymore.
The test case that I’m adding right now is that we have a lingering index entry from a file that has been moved on disk. While the proper fix here would be to ignore such an entry from the index, we should also be more resilient and not fail rename altogether just because there are multiple entries for a USR – the chances are very high that they all translate to the same Swift and Objective-C name.
rdar://123937371
Turns out that translation of sequential to concurrent edits is not trivial to implement. Use the logic in swift-syntax that is already well-tested.
rdar://123880677
We were computing the edits for the rename locations concurrently, which means that we were executing `languageServerType(of:)` concurrently, which could incur concurrent accesses to the `languageServerTypesCache` dictionary.
Introduce an actor `LanguageServerTypesCache` that manages the cache, eliminating the race.
When translating editor placeholders to snippets, we should not include internal parameter names into the snippet. The problem is that once you leave snippet editing mode (essentially by moving the cursor to any place that’s not the snippet, eg. by typing a string literal for one of the parameters or moving the cursor), all snippets become verbatim text. And then it’s impossible to tell whether `paramName: ` was an annotation inside the snippet describing the internal parameter’s name or the external parameter label.
rdar://123772474
For example in the following, we should show `proto.foo()` as a call when computing the call hierarchy of `MyStruct.foo`. Otherwise `MyStruct.foo` does not have any calls, which is misleading.
```swift
protocol MyProtocol {
func foo()
}
struct MyStruct: MyProtocol {
func foo() {}
}
func test(proto: MyProtocol) {
proto.foo()
}
```
rdar://123837232
We might have duplicate results for multiple references inside a macro. In this case we only want to show the macro attribute or macro expansion expr/decl once.
Fixes#1047
rdar://122237704
