Whenever we get request for a document, open it or edit it, trigger a preparation of its target, but don’t block any interaction based on it. This should ensure that the target is usually prepared when the user is interacting with it.
We need to track the preparation status of targets somewhat accurately in `SemanticIndexManager`, so we don’t unnecessarily re-prepare a target. When updating the index store, it is acceptable to schedule another `UpdateIndexStoreTaskDescription` because it will early exit based on an `mtime` check with the unit file. Null builds of a target take significantly longer and thus we want to avoid them.
Fixes#1252
rdar://127474003
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 makes it a lot easier to work on background indexing because you can easily see how background indexing is making progress.
Resolves#1257
rdar://127474057
This follows the general paradigm that callbacks shouldn’t carry much state and instead only notify an observer that state has changed, which the observer can then poll.
When `SwiftPMBuildSystem` operates on a ` .index-build` directory, it owns the checkouts and is thus also allowed to resolve the package versions. This is necessary
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
When renaming `func test(foo: Int) {}` to `test2(foo:)`, rename used to report an edit from `foo` to `foo`, which clutters the refactor preview view. We shouldn’t report edits if no text is actually changed.
rdar://127291815
Renaming an enum case currently caused invalid code to be generated because we would rename eg. `myCase(String)` to `myNewCase(_ String)`.
Fixing the underlying issue requires changes to `sourcekitd`, that are out-of-scope at the moment. For now, just suppress argument label rename for enum cases in SourceKit-LSP and avoid generating invalid code even if just the base name is modified.
rdar://127248157
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.
There were two issues with Objective-C XCTest discovery:
1. We were relying on syntactic test discovery after a document is edited. But since we don't have syntactic test discovery for Objective-C tests, this meant that all tests would disappear as a document got edited. Until we get syntactic test discovery for Objective-C, use the semantic index to discover tests, even if they are out-of-date.
2. We were assuming that the `DocumentSymbols` request returned `[DocumentSymbol]` to find the ranges of tests. But clangd returns the alternative `[SymbolInformation]`, which meant that we were only returning the position of a test function’s name instead of the test function’s range.
rdar://126810202
Implements an initial background index when the project is opened.
The following will be implemented in follow-up PRs:
- Resolving package dependencies
- Preparing dependent modules
- Watching for file updates
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.
