In SourceKit-LSP, we can get into the following situation:
1. We open A.swift
2. We issue a request for A.swift, the request takes a while to execute
3. The dependencies of A.swift are updated, which causes us to reopen the document in sourcekitd, so that the AST is rebuilt
4. This shouldn’t cause the request from (2) to be cancelled. We should continue executing it and only re-open the document after the request from (2) has finished
rdar://127475366
The fact that they are coming from a service named `sourcekitd` should be an implentation detail of SourceKit-LSP and shouldn’t be exposed to users. Use the generic `SourceKit` term, which is vague about which SourceKit the diagnostics are coming from.
This meant that if there were two newlines before the declaration, the documentation would be separated to the declaration by one newline and if the declaration was at the start of a line, the declaration would be on the same line as the doc comment, effectively making the documentation part of a comment.
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.
Merge the XCTests and swift-testing tests defined in extensions into
their parent TestItems.
This is done as another pass after the TestScanner visitors have walked
the tree.
Fixes#1218
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:
Rather than only adapt refactoring actions that conform to
SyntaxRefactoringProvider, which takes a syntax node and produces a
syntax node, adapt to the less-constraining EditRefactoringProvider,
which takes a syntax node and produces edits. We can map edits over
just as effectively.
When the semantic index is out-of-date, we currently purely rely on the syntactic index to discover tests and completely ignore data from the semantic index. This may lead to confusing behavior. For example if you have
```
class MightInheritFromXCTestCaseOrNot {}
class MyClass: MightInheritFromXCTestCaseOrNot {
func testStuff() {}
}
```
Then we don’t return any tests when the semantic index is up-to-date. But once the file is modified (either on disk or in-memory), we purely rely on the syntactic index, which reports `testStuff` as a test method. After a build / background indexing finishes, the test method disappears again.
We can mitigate this problem as follows: If we have stale semantic index data for the test file, for every test method found by the syntactic index, check if we have an entry for this method in the semantic index. If we do, but that entry is not marked as a test class/method, we know that the semantic index knows about this method but decided that it’s not a test method for some reason. So we should ignore it.
rdar://126492948
Test specified with anonymous arguments would produce an id with extra
whitespace, i.e: `funcWithArgument(_ x: Int)` would produce a TestItem
id of `funcWithArgument(_ :)`
This patch trims this extra whitespace to produce IDs that are
consistent with Swift's function ids, i.e: `funcWithArgument(_:)`
Leverage the newly-introduced package manifest editing tools in SwiftPM
to create a package editing refactoring operation. This operation can
be triggered from the a target in the manifest itself, e.g.,
.target(name: "MyLib")
and will add a test target to the package manifest that depends on
this target, i.e.,
.testTarget(
name: "MyLibTests",
dependencies: [ "MyLib" ]
)
It will also create a new source file `Tests/MyLibTests/MyLibTests.swift`
that that imports both MyLib and XCTest, and contains an XCTestCase subclass
with one test to get you started.
Add a `components` property to MemberAccessExprSyntax that provides all
the base names and the member's name as an array. When resolving
swift-testing Tags check if they start with Tag or Testing.Tag and drop
that from the name.
Add a `components` property to MemberAccessExprSyntax that provides all
the base names and the member's name as an array. When resolving
swift-testing Tags check if they start with Tag or Testing.Tag and drop
that from the name.
When the client sends us `workspace/didChangeWatchedFiles` notification of an updated `.swift` file, we should refresh the other open files in that module since they might be referencing functions from that updated file.
If a `.swiftmodule` file has been updated, we refresh all the files within the package since they might import that module. Technically, we would only need to refresh files that are in module that are downstream of the updated module but we don’t currently have that information easily available from SwiftPM. Also, usually, if the client has a file from a low-level module open, he’ll be working on that module which means that such an optimization won’t help. The real solution here is to wait for us to finish preparation (which we would exactly know when it finishes since sourcekit-lsp would schedule it) but for that we need to implement background preparation.
Fixes#620Fixes#1116
rdar://99329579
rdar://123971779
