Update minimum supported Swift version to Swift 5.7

[calda]

Based on the current set of CI jobs, SwiftFormat currently supports a minimum Swift version of Swift 5.2, which was released in Feb 2020.

In #1832, we had been talking about using multiple-trailing-closure syntax for a new feature. Multiple trailing closures were introduced in Swift 5.3, so to use this approach we have to update the minimum supported Swift version.

@nicklockwood, what are your general thoughts on what Swift versions should be supported by SwiftFormat?

We could just update to Swift 5.3+, which would lets us use trailing closures. I personally like the sound of Swift 5.7, since it adds a lot of extra functionality that we're missing in Swift 5.2 while still being somewhat older (released in September 2022).

[codecov]

Codecov Report

Attention: Patch coverage is 92.36111% with 11 lines in your changes missing coverage. Please review.

Project coverage is 94.25%. Comparing base (df3106b) to head (dbd22c8).

Files	Patch %	Lines
Sources/CommandLine.swift	66.66%	5 Missing ⚠️
Sources/GitFileInfo.swift	0.00%	2 Missing ⚠️
Sources/ParsingHelpers.swift	60.00%	2 Missing ⚠️
Sources/Inference.swift	80.00%	1 Missing ⚠️
Sources/SwiftFormat.swift	75.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1837      +/-   ##
===========================================
+ Coverage    94.15%   94.25%   +0.10%     
===========================================
  Files          132      132              
  Lines        17128    17123       -5     
===========================================
+ Hits         16127    16140      +13     
+ Misses        1001      983      -18     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nicklockwood]

Historically, the reason for wanting to keep the codebase building on very old versions was due to a quirk of how people integrated SwiftFormat into their projects.

They either had to build it locally on their dev machine, or if they were using Cocoapods to install the binary then even though it was precompiled they were still limited to whatever version the podfile said was needed to build it.

Since we don't have any analytics about which Xcode versions people are using it's difficult to tell what's safe. I guess an option would be to just bump the version to 5.7 for the next release, but without adopting any features into the code yet, and then see if anyone raises a ticket about it? If so we can roll the min version back in a point release.

[calda]

That makes sense and sounds reasonable.

It would be nice to be able to land #1832, which requires Swift 5.3+.

What if we do this:

1. Drop support for Swift 5.2 now, require Swift 5.3+
2. Merge Move rule examples below rule implementation #1832 which requires Swift 5.3
3. In the next release, bump the minimum Swift version to Swift 5.7
4. If issues come up, we can roll back to Swift 5.3.

What do you think @nicklockwood?

Also, how should we do #3? If we update develop now, the code will inevitably stop compiling with the Swift versions we dropped. I guess that's ok though, since any issues would be easy enough to fix by hand later if necessary. We could avoid changing the --swiftversion to 5.7 for now to reduce the number of incompatible changes.

[nicklockwood]

@calda sorry for the delayed response. I'd suggest doing this in two steps:

1. bump the min version to 5.3 and land the examples change
2. (as a separate PR) bump the minimum version to 5.7 but don't update the code with any 5.7-specific features

If no issues arise during the SwiftFormat 0.55.x release cycle we can update the formatting version and start using 5.7-specific features in the codebase, but otherwise we'll roll back to 5.3 for now

[calda]

I see you did the Swift 5.3 update in b3b2610, thanks!