Danny Mösch

`--fix` fixes what's fixable. Nothing else is reported. Thus, `--strict` doesn't have an effect. A check could be added that warns about `--strict` not having any effect if it comes...

I'll keep this open awaiting your feedback.

I get the confusion now. With `--fix` being an option of `lint`, people expect the normal `lint` behavior with automatic fixes for correctable rules on top. This would be different...

Danger doesn't like merge commits. Please rebase your branch onto `main` instead of merging `main` in.

To be honest, I don't deem this rule to be as useful as I intentionally thought. The OSS report contains a lot of false positives. It's pretty common to conform...

@rcole34: You originally contributed the rule. Mentioning you in case you are interested in a chat with @chriscm2006. Unfortunately, I don't have enough experience in this area to judge the...

Might be a version conflict as SwiftLint requires SwiftSyntax starting from version 510.0.2 while the log lists 509.1.1.

In case you are using the SwiftLint plugin in your builds, please consume it from [this dedicated repository](https://github.com/SimplyDanny/SwiftLintPlugins). It comes without any dependencies and so doesn't cause such issues (given...

Please help me to understand what this "SwiftLint helper" is supposed to do. Also bear in mind, that SwiftLint can be run from the command line with a different "reporter"...

The idea behind the `blanket_disable_command` rule is like: People might just write `// swiftlint:disable` while they should use `// swiftlint:disable:this`, `// swiftlint:disable:next` or `// swiftlint:disable:previous` to be very explicit about...