[SR-16106] Once SourceKit-LSP supports formatting, run formatter on text inserted by CodeActions

[adam-fowler]

Previous ID	SR-16106
Radar	None
Original Reporter	@adam-fowler
Type	Bug

Environment

swift-driver version: 1.45.2 Apple Swift version 5.6 (swiftlang-5.6.0.323.62 clang-1316.0.20.8)

Target: x86_64-apple-macosx12.0

Additional Detail from JIRA

Votes	0
Component/s	SourceKit-LSP
Labels	Bug
Assignee	None
Priority	Medium

md5: 46482d3680d87dc38282b4865db4ef55

Issue Description:

The following list of Code Actions do not include the correct spacing

• Generate Member Initializer

• Expand Switch Cases

• Collapse Nested If Statements

• Move to Extension

• Extract Expression

• Extract Repeated Expression

• Extract Method

• Convert To Switch Statement

For example if I have the following struct

struct Test {
    let a: Int
}

The "Generate Member Initializer" code action produces

struct Test {
internal init(a: Int) {
self.a = a
}
    let a: Int
}

I haven't been able to test all the refactor kinds so there may be others that need fixed as well.

"Add Equatable Conformance" is an example of a code action that generates the correct spacing.

[ahoppen]

This behavior is intended on the SourceKit-side.

The assumption is that the editor will re-indent the lines based on its own indentation settings. "Add Equatable Conformance" provides correct indentation is because it was implemented by an external contributor and I believe he didn’t know that he didn’t need to worry about indentation.

Once SourceKit-LSP support code formatting, we should run the formatter on the code that should be inserted by the refactoring.

[ahoppen]

rdar://95587750

[plemarquand]

Now that swiftlang/swift-format#708 has been merged in swift-format to support formatting a range is that everything we need to fix this?

[ahoppen]

swiftlang/swift-format#708 hasn’t been cherry-picked to release/6.0, which means that we can’t use it from SourceKit-LSP 6.0. I also just remembered that swift-format can only format valid Swift code. This means that if your file has syntax errors after a refactoring (could be somewhere unrelated to the refactoring), then running swift-format won’t work.

[plemarquand]

I'd have to try it, but it should be possible that when formatting a range, as long as the code within that range is valid, then swift-format should work even if code outside the range isn't valid Swift.

[ahoppen]

I think swift-format does not format if it can’t build a syntax tree for the source file and the range formatting is done after building the syntax tree, so I’d be surprised if range formatting worked in the presence of error inside the file.