* Migrate `implicitly_unwrapped_optional` to SwiftSyntax
* Update Source/SwiftLintFramework/Rules/RuleConfigurations/ImplicitlyUnwrappedOptionalConfiguration.swift
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
* Fix after rebase
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
A long-standing limitation with SourceKit's "editor open" request is
that we weren't able to get certain tokens, such as braces, brackets and
parentheses.
This meant that this code block would be counted as two lines:
```swift
print(
"hi"
)
```
because the trailing `)` would be treated as a whitespace line.
This meant that our "body length" family of rules that measure the
effective line count of declarations like functions, types or closures
would often significantly under-count the number of content lines in a
body.
Now with SwiftSyntax, we can get all tokens, including the ones
SourceKit was previously ignoring, so we can get much more accurate line
counts when ignoring whitespace and comments.
In addition, we weren't very thorough in how we measured body length.
As an exercise, how many lines long would you say the body of this
function is?
```swift
func hello() {
print("hello")
}
```
Does the body span one line or three lines?
I propose that we consistently ignore the left and right brace lines
when calculating the body line count of these scopes so that we measure
body line counts like this:
```swift
// 1 line
{ print("foo") }
// 1 line
{
}
// 1 line
{
print("foo")
}
// 2 lines
{
let sum = 1 + 2
print(sum)
}
```
Now with those changes in place, in order to keep the default
configuration thresholds to similar levels as before, we need to adjust
them slightly. Here's what I'm suggesting:
|Rule|Before|After|
|-|-|-|
|closure_body_length|20/100|30/100|
|function_body_length|40/100|50/100|
|type_body_length|200/350|250/350|
This is a pretty significant breaking change and I suspect we'll hear
from users who are surprised that some of their declarations now exceed
the rule limits, but I believe this new approach to calculating body
lines is more correct and intuitive compared to what we've had until
now.
OSSCheck is also going to report a bazillion changes with this, which is
expected given the scope of this change.
* Move generated rule tests to a dedicated GeneratedTests target
* Move integration tests to a dedicated IntegrationTests target
This will improve bazel cacheability by having fewer tests depend on all
lint inputs, which are only needed by the integration tests.
With SwiftSyntax rewriters, the visitors get called with the new nodes
after previous mutations have been applied, so it's not straightforward
to translate those back into the original source positions.
So only check the first locations.
By using SwiftSyntax instead, we avoid the overhead of a SourceKit
request, which has a significant impact if none of the rules being
corrected use SourceKit.
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`
To enforce that `self` identifiers are consistently re-bound to a common
identifier name.
Configure `bind_identifier` to the name you want to use.
Defaults to `self`.
Addresses https://github.com/realm/SwiftLint/issues/2495
Run with `bazel test --spawn_strategy=standalone //Tests/...`
Consumers who define rules via `swiftlint_extra_rules` can run tests for
their custom rules too:
```
./bazelw test \
--spawn_strategy=standalone \
@SwiftLint//Tests:ExtraRulesTests
```
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.
Marcelo Fabri
