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.
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.
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.
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" }
}
