Rule Request: [disable_rationale]

New Issue Checklist

• [ *] Updated SwiftLint to the latest version
• [* ] I searched for existing GitHub issues

New rule request

Please describe the rule idea, format
this issue's title as Rule Request: [Rule Name] and describe:

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.

I would like to have an explanation of why a rule is disabled next to it

2. Provide several examples of what would and wouldn't trigger violations.

• would:

// swiftlint:disable missing_docs

• would not:

// This rule is disabled because of blablabla
// swiftlint:disable missing_docs

3. Should the rule be configurable, if so what parameters should be configurable?
   No configuration required.

4. Should the rule be opt-in or enabled by default? Why?
   See README.md for guidelines on when to mark a rule as opt-in.
   Opt-in.

Custom rule implementation

At the same time I am proposing this rule, I tried to implement it as a custom rule. I did not managed, and I would appreciate some help. My main idea is:

(1) Find a line containing 'swiftlint:disable' ==> (2) Check that the previous line is a comment

I thought I could do this with a lookbehind regex. The closest I got was the following regex:

custom_rules:
  disabled_rules_rationale:
    regex: "(?<!\/\/[^\n]*$\n)^[^\n]*swiftlint:disable"
    match_kinds:
      - comment
    message: "All swiftlint disable comments should include an explanation on top"

In https://regexr.com the outcome is the desired one:

But using the same regex in swiftlint does not result the same (note there are no errors):

Some final notes:

• I am using [^\n] instead of . in the regex because I did not manage to make . work in swiftlint.
• The [^\n]* part of the lookbehind group in the "(?<!\/\/[^\n]*$\n)^[^\n]*swiftlint:disable" regex is the one making things not work: using "(?<!\/\/$\n)^[^\n]*swiftlint:disable" has the following result, which is very close to the intended behaviour:

Thanks!

Start with README.md's opt-in-rules guidance and the custom_rules configuration shown in the issue. Compare the provided violating and non-violating examples, then investigate how SwiftLint processes swiftlint:disable comments and multiline regexes. Done means a rule can require an explanation comment immediately above each disable comment, with no configuration required.