Swift 5.2 has been officially released for over 7 months now, there's no
reason to keep supporting earlier versions when _building_ SwiftLint.
However, SwiftLint still supports _linting_ back up to Swift 3.0.
* Mark Swift 5 as supported
* Only set a single Swift version on podspec
Multiple swift versions requires CocoaPods 1.7.0, which is still
in beta.
* Modernize ruby hash syntax
* Update SourceKitten to 0.23.1
* Update project to compile with Xcode 10.2
* Fix explicit_acl with Swift 5
* Update macOS VM image
* Fix ConfigurationTests on Swift 5
* Update Podspec
* Workaround SR-10486 to fix validation tests
* Fix testDetectSwiftVersion on Swift 5
* Update specs repo when validating CocoaPods spec
* Fix redundant_set_access_control tests
* Manually update Package.resolved
* Use .upToNextMinor
* [Azure Pipelines] Add `sw_vers`
* Relax expecting conditions for crashing output in `testSimulateHomebrewTest()`
Because TSAN makes `swiflint` to produce additional output on crashing.
* Add CHANGELOG entry
* Ignore extensions in explicit ACL rules
* Work around SR-10486 for Sourcery
This bumps the minimum version required to build SwiftLint to 4.2. The primary motivating factor to drop support for Swift 4.0-4.1.x is that SwiftLint now uses CryptoSwift, which requires 4.2.
* Add changelog entry
* Remove --allow-warnings flag from CocoaPods commands
* Update CryptoSwift to 0.13.0
* Migrate to Swift 4.2
* Remove CircleCI tests for Swift < 4.2
* Update English and Chinese README
Korean README doesn't yet have a version table like this.
* Update gems
* Add changelog entry for fixed compiler warnings
* Update CocoaPods to 1.6.0.beta.2
To work around https://github.com/CocoaPods/CocoaPods/issues/7708
Performance has gotten pretty bad for complex SwiftLint configurations like the one used for Lyft's iOS code base involving lots of files in the directories being linted, large configuration files and many nested configuration files.
Two main areas were particularly ripe for improvement were:
1. Collecting which files to lint
2. Lint cache lookups
### Collecting which files to lint
Improve this by:
* using an NSOrderedSet to remove excluded paths instead of `Array.filter`
* parallelizing calls to `filesToLint` for all paths to lint and exclude
* using `FileManager.subpaths(atPath:)` instead of `enumerator(atPath:)`
|Change|Before|After|Speed up|
|-|-|-|-|
|NSOrderedSet|2.438s|0.917s|2.659x|
|Parallel Flat Map|2.438s|2.248s|1.085x|
|Subpaths|0.939s|0.867s|1.083x|
|**Total**|**2.438s**|**0.720s**|**3.386x**|
### Lint cache lookups
By using an MD5 hash of the Configuration description from CryptoSwift as the cache key instead of instead the full description, we can drastically speed up cache lookups for projects with complex SwiftLint configurations. I think the dictionary lookup for very large string keys doesn't perform very well.
---
* Speed up Configuration.lintablePaths
* Improve cache lookup performance by up to 10x
By using an MD5 hash of the Configuration description from CryptoSwift
as the cache key instead of instead the full description.
* Add changelog entries
* Swift 4.0 & Linux compatibility
* os(Darwin) isn't a thing
* Allow warnings in pod lib lint
SwiftLint supports building with Swift 4.0 to 4.2.
There is no version of CryptoSwift to support both Swift 4.0 and
Swift 4.2.
So allow warnings for now. We'll make one more Swift 4.0 compatible
release, then we'll bump the build requirements to Swift 4.2 and
remove the `--allow-warnings` flag.
JP Simard