Uses SwiftSyntax 5.5 on Linux when building with Swift 5.5. We use the 5.6 version of
SwiftSyntax when building with Swift 5.5 and 5.6 on macOS because we statically link
`lib_InternalSwiftSyntaxParser` thanks to
https://github.com/keith/StaticInternalSwiftSyntaxParser/releases/tag/5.6.
This keeps SwiftLint binaries portable across machines on macOS, regardless of
_where_ or even _if_ `lib_InternalSwiftSyntaxParser` is installed.
* Run TSan CI job with `--configuration release` to avoid stack overflows
* Add Swift 5.6 CI job
* Fix linker settings
SourceKitten: 0.31.1 to 0.32.0
SWXMLHash: 5.0.2 to 6.0.0
Also prevent swift-argument-parser from being updated to 1.1.0 which is
incompatible with our macOS version support.
Since `_InternalSwiftSyntaxParser` isn't in the search paths when building with the `-static-stdlib` flag, we have to manually pass an include path so the swift compiler discovers it. Unfortunately we cannot just pass `-I/usr/lib/swift` because that results in duplicate library errors since the libraries we're linking statically also live there as shared libraries. This first symlinks the module definition to the root of the checkout and uses `.` for the `-I`. Any temporary path could be used instead.
We've tried adding Swift Syntax support to SwiftLint in the past but had to turn it off in https://github.com/realm/SwiftLint/pull/3107 due to distribution and portability issues.
With https://github.com/keith/StaticInternalSwiftSyntaxParser it should be possible to avoid those issues by statically linking the internal Swift syntax parser so it's available no matter where users have Xcode installed on their computer.
By removing all calls to SourceKit (collecting comment commands + checking the current Swift version), there's a really significant performance improvement.
| Framework | Mean [ms] | Min [ms] | Max [ms] | Relative |
|:---|---:|---:|---:|---:|
| SourceKit | 517.8 ± 8.3 | 505.5 | 531.1 | 6.59 ± 0.43 |
| SwiftSyntax | 78.6 ± 5.0 | 72.6 | 92.1 | 1.00 |
In practice, the SourceKit overhead will continue being there for as long as any rule being run is still looking up the SwiftLint syntax map though.
* Disable Swift 5.4 CI jobs
* Remove SwiftLintFramework podspec
I couldn't find a single use in GitHub's search: https://github.com/search?q=SwiftLintFramework+filename%3APodfile+language%3ARuby+language%3ARuby&type=Code
Just not worth maintaining anymore.
* Change package swift tools version to 5.5
* Update docker_test to use Swift 5.5 image
* Clean up old Swift versions in SwiftVersionTests
Even though these older Swift versions should still be supported, these tests
can't be built against those versions so they're useless.
* Run docker commands with `--platform linux/amd64`
* Remove LinuxMain
It looks like tests are discovered dynamically on Linux as of recent
SwiftPM versions.
The option can be used if an example has mainly been added as another test case, but is not suitable
as a user example. User examples should be easy to understand. They should clearly show where and
why a rule is applied and where not. Complex examples with rarely used language constructs or
pathological use cases which are indeed important to test but not helpful for understanding can be
hidden from the documentation with this option.