Danny Mösch

This still sounds to me like this should be fixable in the pipeline configuration. But that's just guessing. On the SwiftLint side, I wouldn't dare to change the behavior as...

In the configuration file, to every rule, you can add a `severity` option than can be set to `error` or `warning`. For example: ```yml force_try: severity: error ```

There is currently no way to ignore violations in string blocks and I don't see a good way to support a restriction for single lines. ```swift // swiftlint:disable force_unwrapping let...

The reason you don't get a warning in the second case (explicitly conforming to `Actor`) might be the option `excludes_inherited_types` which is `true` by default. However, I agree that the...

> Hi, Can I work on this?🙂 Sure. Please go ahead.

> I tried to fix this. But as I saw some merged pull requests that rewriting to use Swift Syntax, would I better to change whole file to Swift Syntax...

@marunomi: The PR that rewrites this rule with SwiftSyntax just got merged. It ought to be a bit easier now to implement your enhancement. So please go ahead by rebasing...

> @SimplyDanny Thank you for your kind reviews. The CI is currently failing and I would like to know why it is failing as I cannot find the cause on...

> @SimplyDanny > > I rebased my branch onto current main branch, but CI still fail... Merge is not the same as rebase. 😉 Danger fails because of merge commits...

Actually, it shouldn't be surprising that Swift packages depend on other packages transitively. However, on macOS, the SwiftLint plugin depends on a compiled binary only. So the sources shouldn't be...