Also include redundant void return clauses for closures in addition to
functions. This can be disabled by configuring the rule with
`include_closures: false`.
Co-authored-by: JP Simard <jp@jpsim.com>
Advantages of having typical errors at a common place:
* Error message styling can be harmonized
* Existing messages can be reused
* Overview of prefixes ('error: ', 'warning: ')
* Manage how to print them to the console
The CLI target shouldn't be importing SwiftLintFramework with
`@_spi(TestHelper)`. If the CLI target needs to access something in
SwiftLintFramework, that declaration should be `public`.
This will allow for registering rules that aren't compiled as part of
SwiftLintFramework.
Specifically this will allow us to split the built-in and extra rules
into separate modules, leading to faster incremental compilation when
working on rules since the rest of the framework won't need to be
rebuilt on every compilation.
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.