This change includes a number of new refactoring code actions that
build on the syntax refactorings for the SwiftRefactor module of swift-syntax:
* Add digit separators to an integer literal, e.g., `1000000` ->
`1_000_000`.
* Remove digit separators from an integer literal, e.g., 1_000_000 ->
1000000.
* Format a raw string literal, e.g., `"Hello \#(world)"` ->
`##"Hello\#(world)"##`
* Migrate to new if let syntax, e.g., `if let x = x { ... }` ->
`if let x { ... }`
* Replace opaque parameters with generic parameters, e.g.,
`func f(p: some P)` --> `func f<T1: P>(p: T1)`.
This is generally easy to do, requiring one conformance to provide a name for the refactoring:
extension AddSeparatorsToIntegerLiteral: SyntaxRefactoringCodeActionProvider {
public static var title: String { "Add digit separators" }
}
Eg. when requesting type hierarchy of a class when the project hasn’t been built, sourcekit-lsp returns an empty array. That causes VS Code to fail with very ambiguous error messages
- MISSING provider
- Cannot read properties of null (reading 'kind')
To work around this, instead of returning an empty array, return `nil` instead.
rdar://126228814
Eg. if we have the following, and we get the call hierarchy of `foo`, we only want to show `bar` once, with multiple `fromRanges` instead of having two entries for `bar` in the call hierarchy.
```swift
func foo() {}
func bar() {
foo()
foo()
}
```
Instead of returning `nil` to indicate that the position conversion failed, log a fault and perform a best-effort recovery.
I think this allows us to perform better recovery and also makes code calling these position conversions a lot simpler because it doesn’t need to make decisions about what to do if position conversions fail.
This ways the client doesn’t need to create a hierarchical structure using the container names. It is also more flexible and allows nesting of test suites + the addition of labels and tags for swift-testing.
The data structure for `TestItem` has been heavily inspired by VS Code’s `TestItem` for the test explorer, which should make it fairly straightforward to integrate these results into the VS Code test explorer.
Instead of logging errors in position translation ad-hoc at the caller’s side (and ofter forgetting to do so), log these errors in `LineTable`. To be able to debug where the position conversion error is coming from, also log the file name and line number of the caller.
rdar://125545620
VS Code rejects the placeholder name returned by the `PrepareRenameRequest`. When initiating rename on `x` in the following, this means that VS Code picks its own internal symbol name as the placeholder text, opening the rename textbox with `x`.
```swift
func foo(
x: Int
) {}
```
Users then enter `y` in the expectation to rename only the parameter but sourcekit-lsp expects a function name and thus renames `foo` to `y(x:)`, which is unexpected.
rdar://125551489
If the index for a given file is not up-to-date, perform a syntactic scan for tests within it.
This should allow editors to run the `textDocument/tests` request while the user is editing a file to scan it for test cases.
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
