This change makes it possible to add native custom rules when building
SwiftLint via Bazel (possible as of
https://github.com/realm/SwiftLint/pull/4038).
First, add a local bazel repository where custom rules will be defined
to your project's `WORKSPACE`:
```python
local_repository(
name = "swiftlint_extra_rules",
path = "swiftlint_extra_rules",
)
```
Then in the extra rules directory, add an empty `WORKSPACE` and a
`BUILD` file with the following contents:
```python
filegroup(
name = "extra_rules",
srcs = glob(["*.swift"]),
visibility = ["//visibility:public"],
)
```
To add a rule (for example, `MyPrivateRule`) add the following two
files:
```swift
// ExtraRules.swift
func extraRules() -> [Rule.Type] {
[
MyPrivateRule.self,
]
}
```
```swift
// MyPrivateRule.swift
import SourceKittenFramework
import SwiftSyntax
struct MyPrivateRule: ConfigurationProviderRule {
var configuration = SeverityConfiguration(.error)
init() {}
static let description = RuleDescription(
identifier: "my_private_rule",
name: "My Private Rule",
description: "This is my private rule.",
kind: .idiomatic
)
func validate(file: SwiftLintFile) -> [StyleViolation] {
// Perform validation here...
}
}
```
Then you can reference the rule in your configuration or source files as
though they were built in to the official SwiftLint repo.
This means that you have access to SwiftLintFramework's internal API.
We make no guarantees as to the stability of these internal APIs,
although if you end up using something that gets removed please reach
out and we'll make a best effort to maintain some level of support.
This PR also improves the linter cache on macOS to make it correctly
invalidate previous results when custom native rules are edited. This
even works when doing local development of SwiftLint, where previous it
was necessary to use `--no-cache` when working on SwiftLint, now the
cache should always work.
Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
This will unblock using Swift Concurrency features and updating to the
latest versions of Swift Argument Parser.
This won't drop support for linting projects with an older toolchain /
Xcode selected, as long as SwiftLint was _built_ with 5.6+ and is
_running_ on macOS 12+. So the main breaking change for end users here
is requiring macOS 12 to run.
However, the upside to using Swift Concurrency features is worth the
breaking change in my opinion. Also being able to stay on recent Swift
Argument Parser releases.
* Split cache into one file per configuration
* Only write cache files with changes
* Avoid converting from Data -> String -> Data when saving cache files
* Move empty check to for where
* Split cache changelog entry
* Reword changelog entry to better reflect impact
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.
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.
This has never worked for two reasons:
1. We've used dictionaries to represent cache descriptions, which
don't guarantee stable ordering of keys across invocations.
This is true both on Darwin and Linux, but in practice ordering
varies significantly more on Linux.
2. Storing a `TimeInterval` value in a `[String: Any]` dictionary
and retrieving it again will not be dynamically castable to
`Double` or `TimeInterval` but will be castable to `Int`.
also slightly speed up writing to the cache.
For example, on the Lyft codebase with 1,500 Swift files:
```bash
$ time swiftlint lint --quiet
swiftlint --quiet 3.53s user 0.27s system 388% cpu 0.979 total
$ rm -rf ~/Library/Caches/SwiftLint && time swiftlint lint --quiet
swiftlint --quiet 35.20s user 1.22s system 371% cpu 9.806 total
$ time swiftlint lint --quiet
swiftlint lint --quiet 0.90s user 0.13s system 218% cpu 0.472 total
$ rm -rf ~/Library/Caches/SwiftLint && time swiftlint lint --quiet
swiftlint lint --quiet 31.78s user 1.18s system 360% cpu 9.146 total
```
`fatalError` prints the full path of the file, which leaks filesystem information from the machine that built the binary. Now that we release via CocoaPods, this is more critical.
JP Simard
