Danny Mösch

The `inclusive_language` rule provides the configuration option `override_allowed_terms` that exists exactly to exclude these kinds of false-positives. Adding ```yml inclusive_language: override_allowed_terms: ["mastery"] ``` to your `.swiftlint.yml` file should do the...

The configuration is expressive enough to overcome the issue. In fact, every false-positive can be fixed by configuration easily. I don't see an urgent need for improvement here.

This behavior can be observed with all rules writing directly to the file when correcting. It's not only about the `vertical_whitespace*` rules. They perform the fix and immediately write the...

To make the rule even faster especially in huge source files, traversing the AST could be stopped as soon as a class, struct or enum is encountered as only extension...

The existing rule is unable to know the type of the identifier in the switch condition. This knowledge is only available in a type-checked AST that would be available in...

The reported violations are not new. They must have already been there before the change.

One solution would be to add a configuration option to exclude type aliases and associated types from the analysis of the rule.

I cannot reproduce the issue with the provided example and configuration. It perhaps has meanwhile been fixed. Can you confirm?

These rules do not know anything about the type hierarchy. Being AST-based, they only check whether there is `XCTestCase` in the inheritance list. It would be an option to add...

> So I just had a go at adding an `xctestcase_subclasses` option to `test_case_accessibility`, which seemed pretty easy as it already has a configuration, and I got it working on...