added `ConvertStringConcatenationToStringInterpolation` to convert string concatenation to string interpolation:
- the string concatenation must contain at least one string literal
- the number of pound symbols in the resulting string interpolation is determined by the highest number of pound symbols among all string literals in the string concatenation
- multiline string literals are not supported
registered in `SyntaxCodeActions.allSyntaxCodeActions`
registered in Sources/SourceKitLSP/CMakeLists
created a test in `CodeActionTests`
In some Swift 6 toolchains, the diagnostic about missing protocol requirements is emitted on the protocol in the inheritance clause instead of the conforming type. Relax a few assertions in the tests.
Addresses a few minor comments and the following major ones:
- Add test cases for the syntax refactorings
- Don’t report code actions for refactorings that don’t actually modify the source
- Instead of just looking at the parent of the token of the selected range, walk up the syntax tree to find the syntax node to refactor. This makes the refactorings available in a lot more locations.
Add a syntactic action that takes JSON pasted into a Swift file or
placed in a string literal, then turns it into a set of Codable
structs that can represent the JSON. Our typical example starts like
this:
```
{
"name": "Produce",
"shelves": [
{
"name": "Discount Produce",
"product": {
"name": "Banana",
"points": 200,
"description": "A banana that's perfectly ripe."
}
}
]
}
```
and turns into this:
```swift
struct JSONValue: Codable {
var name: String
var shelves: [Shelves]
struct Shelves: Codable {
var name: String
var product: Product
struct Product: Codable {
var description: String
var name: String
var points: Double
}
}
}
```
When converting to JSON, we attempt to reason about multiple JSON
objects on the same level to detect when there are optional fields,
due to either an explicit null or due to the absence of fields in some
of the JSON objects that are conceptually stored together.
The refactoring itself would live down in the swift-syntax package if
not for its dependency on Foundation. We'll move it when appropriate.
This code action takes an undocumented function declaration like
func refactor(syntax: DeclSyntax, in context: Void) -> DeclSyntax?
and adds stub documentation for the parameters / result / etc., like this:
/// A description
/// - Parameters:
/// - syntax:
/// - context:
///
/// - Returns:
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" }
}
Now that all the types that model test projects are suffixed `Project` instead of `Workspace`, the `ws` abbreviation doesn‘t make sense. It also never really fit with the new style of avoiding abbreviations. Rename all occurrences to `project`.
rdar://124727401
Rename all the classes that write files to disk to create a test project that we can open in sourcekit-lsp to end with `TestProject`. This is better than the old `Workspace` suffix because it avoids ambiguities with the `Workspace` type inside sourcekit-lsp.
- IndexedSingleSwiftFileWorkspace -> IndexedSingleSwiftFileTestProject
- MultiFileTestWorkspace -> MultiFileTestProject
- SwiftPMTestWorkspace -> SwiftPMTestProject
Currently, all tests send publish diagnostics notifications, which is noise in the logs for most tests. Change the tests to use the pull diagnostics model by default and make the push diagnostic model opt-in.
rdar://123241539
Finetune the code
Finetune the code
Finetune the code
Update the code per comments
Use location marker instead of hard coded indexes
Update the test to align the code convention
Rename a variable
Correct unit tests
Format the code
Update Package.swift
Instead of listening for document updates sent from `sourcekitd` and sending a `PublishDiagnosticsNotification` based on the `sourcekitd` notification, wait for a little while and then execute an internal `DocumentDiagnosticsRequest` to load diagnostics and send them to the client.
This has two advantages:
- It unifies the two diagnostic implementations
- It removes the need to keep track of semantic diagnostics in `SwiftLanguageServer`
- It gets us one step closed to opening and editing documents in `syntactic_only` mode. The only thing that is left now are semantic tokens.
- Remove the JSONRPC connection kind between `TestSourceKitServer` and `SourceKitServer`
- It wasn’t actually used and the connection abstraction just made things more complicated than they needed to be
- Send requests and notifications to `SourceKitServer` by directly calling into `SourceKitServer.handle` instead of going through a `Connection`. This makes the code a lot easier to understand statically
- Make `TestSourceKitServer` conform to `MessageHandler` instead of going through `TestClient`
- IMO this centralizes all the handling and makes it a lot easier to follow. `TestClient` didn’t do a whole bunch anyway.
- Allow async awaiting of next notifications instead of having to register a `handleNextNotification` handler before expecting the notification to be emitted.
- This allows us to remove quite a few `XCTExpectation`s in test cases
- Change `sendSync` function that sends a request and returns the result to be `async`
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
The asyncification changes caused some non-deterministic test failures. I believe that some of these are due to race conditions that are the result of the partial transition to actors.
Instead of merging the asyncification piece by piece, I will collect the changes asyncification changes in a branch and then qualify that branch througougly (running CI multiple times) before merging it into `main`.
Unfortuantely, we have a few potential out-of-order exeuction possibilities while we migrate everything else to also be asyncronous. But those should be low-probability issues that we can fix in follow-up commits, so I think it’s fine for now. All of these places are marked with `FIXME: (async)`
Instead of having ad-hoc timeout durations in all the test cases, specify a default timeout duration that can be used by tests.
This allows us increase the timeout duration for all tests if we discover that e.g. sourcekitd is slower in CI setups.
rdar://91615376
#481 replaced SourceKit placeholders (like `<#code#>`) by LSP snippets for code actions, which are used to represent SourceKit refactoring and diagnostic Fix-Its. But LSP snippets are only supported for code completion, not for code actions. This results in LSP snippets like ${1:code} being inserted into the editor.
Instead of replacing SourceKit placeholders by LSP placeholders, we should just remove them altogether from the code action response.
rdar://92447079 [#488]
Previously, we would insert `<#code#>` placeholders when inserting missing protocol requirements (both via the Fix-It and the refactor command). Translate them to LSP placeholders before inserting them.
rdar://92161144
A number of tests were failing with the -Onone lifetime changes.
Regardless of what happens with that change, I'd like to keep our tests
passing with the stricter rules since we also test in release builds.
