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.
SwiftPM 5.3 uses the `XCBuild.framework` to generate universal binaries when it receives multiple `--arch` options.
In that case, `--show-bin-path` returns `.build/apple/Products/Release`.
Xcode has supported Swift Package Manager projects natively since Xcode
11, which has been out for over a year, where you can use Xcode by
having it open the `Package.swift` manifest rather than a `.xcodeproj`
or `.xcworkspace`.
I've been primarily developing SwiftLint in Xcode using this approach
for over a year, and despite a few nitpicks I have, it's been a joy to
use.
So I'd like to completely remove the Xcode project along with things
that support it:
* `SwiftLint.xcworkspace`/`SwiftLint.xcodeproj`: Neither of these are
needed if we use `xed .` or `xed Package.swift` to develop SwiftLint
in Xcode.
* `Cartfile`/`Cartfile.private`/`Cartfile.resolved`/`.gitmodules`/`Carthage/`:
These were used to manage dependencies as git submodules for use in
the Xcode workspace, but that's no longer necessary if Xcode delegates
to SwiftPM to manage dependencies for us.
* Some scripts can be simplified, cleaned up or even completely removed.
* **Reduce duplication:** Rather than update dependencies or files in
multiples places, there will only be the package manifest and the
Podfile
* **Reduce merge conflicts:** This hasn't been too bad, but it's
occasionally a pain when trying to land old PRs
* **Reduce development overhead:** No need to manually make sure that
files in the Xcode project are sorted alphabetically
* **Reduce clone time:** No need to run
`git submodules update --init --recursive` anymore
I think this breaks Carthage users that pull in SwiftLintFramework as a
dependency in a Cartfile.
However I can't find any references to [`SwiftLintFramework` in any
`Cartfile` files on GitHub](https://github.com/search?q=swiftlintframework+filename%3ACartfile&type=Code&ref=advsearch&l=&l=)
so this doesn't appear to be worth continuing to maintain.
Resolves https://github.com/realm/SwiftLint/issues/3412
Current events have renewed the conversation in our community about the roles of terminology with racist connotations in our software. Many companies and developers are now taking appropriate steps to remove this terminology from their codebases and products. (e.g. [GitHub](https://twitter.com/natfriedman/status/1271253144442253312)) This small rule prevents the use of declarations that contain any of the terms: whitelist, blacklist, master, and slave. It may be appropriate to add more terms to this list now or in the future.
There are a lot of libraries dynamically linked, so it's unlikely to
work in most places other than the same Docker image used to build the
binary (latest official Swift Docker image).
It might still be useful if you can guarantee that you'll use this from
that image.
ldd .build/release/swiftlint
linux-vdso.so.1 (0x00007fff38db5000)
libswiftCore.so => /usr/lib/swift/linux/libswiftCore.so (0x00007f11503cd000)
libFoundation.so => /usr/lib/swift/linux/libFoundation.so (0x00007f114fba6000)
libswiftGlibc.so => /usr/lib/swift/linux/libswiftGlibc.so (0x00007f1151264000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f114f987000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f114f784000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f114f580000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f114f1e2000)
libswiftDispatch.so => /usr/lib/swift/linux/libswiftDispatch.so (0x00007f115122b000)
libdispatch.so => /usr/lib/swift/linux/libdispatch.so (0x00007f114ef82000)
libBlocksRuntime.so => /usr/lib/swift/linux/libBlocksRuntime.so (0x00007f114ed7f000)
libFoundationXML.so => /usr/lib/swift/linux/libFoundationXML.so (0x00007f11511d2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f114e98e000)
libicui18nswift.so.65 => /usr/lib/swift/linux/libicui18nswift.so.65 (0x00007f114e463000)
libicuucswift.so.65 => /usr/lib/swift/linux/libicuucswift.so.65 (0x00007f114e062000)
libicudataswift.so.65 => /usr/lib/swift/linux/libicudataswift.so.65 (0x00007f114c3b3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f114c02a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f114be12000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1151053000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f114bc0a000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f114b849000)
libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f114b491000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f114b274000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f114b04e000)
libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f11494a5000)
This PR adds a new `unused_declaration` analyzer rule to lint for unused declarations.
By default, detects unused `fileprivate`, `private` and `internal` declarations.
Configure the rule with `include_public_and_open: true` to also detect unused `public` and `open` declarations.
Completely remove the `unused_private_declaration` rule.
This is built on the work enabling collecting rule infrastructure in https://github.com/realm/SwiftLint/pull/2714.
* 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
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.
* Enable analyzer_rules in .swiftlint.yml
* Add analyze and analyze_autocorrect commands to Makefile
* Run `swiftlint analyze` on CI
* Run make bootstrap before make analyze
The MIT license doesn't require that all files be prepended with this
licensing or copyright information. Realm confirmed that they're ok with this
change. This will enable some companies to contribute to SwiftLint and the
date & authorship information will remain accessible via git source control.
Danny Mösch
JP Simard
Juozas Valančius
Norio Nomura
Dalton Claybrook
Ilias Karim
Marcelo Fabri
Kyle Fleming
