With the memory increase related to
https://github.com/apple/swift-syntax/issues/921,
I wanted a way to quickly know how much memory was being used by
SwiftLint.
Here's how much memory it took to lint SwiftLint itself at various
versions in the last few weeks:
* 0.49.1: 223 MB
* 0.50.0-rc.1: 356 MB
* 0.50.0-rc.2: 444 MB
* main (458916174): 464 MB
```console
$ swiftlint --progress --benchmark
Linting Swift files in current working directory
529 of 529 [==============================] ETA: 0s (121 files/s)
Done linting! Found 0 violations, 0 serious in 529 files.
Memory used: 464 MB
$ swiftlint --progress --benchmark
Linting Swift files in current working directory
529 of 529 [==============================] ETA: 0s (16220 files/s)
Done linting! Found 0 violations, 0 serious in 529 files.
Memory used: 55.8 MB
```
Added rules filtering options, like in the `rules` subcommand.
<img width="880" alt="generate-docs--help" src="https://user-images.githubusercontent.com/7829589/189372666-2f5aba62-57a1-49dc-9155-c60f9e085984.png">
To achieve reuse with `rules` subcommand:
- extracted filtering logic into `RulesFilter` (and write tests)
- extracted filtering command line parameters into `RulesFilterOptions: ParsableArguments`
And move analyze CI job to Bazel
Which will benefit from caching previous results,
so if we make a PR that doesn't impact the analysis
results (i.e. changelog or docs) we might be able to
skip running this at all.
Prints out something like this on macOS:
```
Version: 0.49.0-rc.1
Build ID: B43931F3-D096-3704-B41C-FC40673A3F96
```
This can be used to determine if two `swiftlint` executables are
identical.
To support this, we first must use an async entrypoint to the CLI, which
we do by changing the lint and analyze commands to conform to
`AsyncParsableCommand`.
The in order to map over the closures with suspension points, we pull in
CollectionConcurrencyKit as a new dependency.
This change does not touch SwiftLintFramework, only the CLI target.
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.
There is no real benefit for this option. Files and folders to lint/analyze
can be passed to `swiftlint` as last arguments. There cannot be multiple
`--path` arguments. If there is more than one only the last path is considered.
* Fix analyzer rules with Xcode 13.3
Looks like starting with Xcode 13.3 / Swift 5.6, cursor info requests
started canceling in-flight requests, so we need to pass
`key.cancel_on_subsequent_request: false` to bypass that.
Analyzer rules on Swift 5.6 are extremely slow, however. Not really
usable right now.
* Run analyzer rules one file at a time
* Add changelog entry
A colleague was confused by the output of `swiftlint autocorrect`, she
couldn't understand why SwiftLint told her it corrected thousands of
files when she only touched one.
The "Done correcting \(files.count) ..." output made her think that a
change was made on each of the `files`, when really they had only been
inspected.
A good solution would be to adopt a similar approach as the `lint`
command does.
Not being familiar with the codebase, I though a good first step could
have been to tweak the message a bit, making it clearer that the count
printed to the console is the inspected files.
* Integrate OS Signposts to help profile SwiftLint performance
* Split LintOrAnalyzeCommand.lintOrAnalyze(_:) into two functions
Using a builder reference type to share common mutable state.
A colleague was confused by the output of `swiftlint autocorrect`, she
couldn't understand why SwiftLint told her it corrected thousands of
files when she only touched one.
The "Done correcting \(files.count) ..." output made her think that a
change was made on each of the `files`, when really they had only been
inspected.
A good solution would be to adopt a similar approach as the `lint`
command does.
Not being familiar with the codebase, I though a good first step could
have been to tweak the message a bit, making it clearer that the count
printed to the console is the inspected files.
JP Simard
