`unavailable_function` and overriding

New Issue Checklist

• I've Updated SwiftLint to the latest version.
• I've searched for existing GitHub issues.

Feature or Enhancement Proposal

The unavailable_function rule reports functions which only have a terminating call (e.g. fatalError) without any return, unless marked available(*, unavailable) or returning Never. However, this can cause false positives when functions are overridden. Consider the following example (main.swift):

class Base {
    func greet() { fatalError("Subclasses must override greet()") }
}
class Derived: Base {
    override func greet() { print("Hello World") }
}
Derived().greet()

and .swiftlint.yml

opt_in_rules:
  - unavailable_function

Running swiftlint . will report:

main.swift:2:5: warning: Unavailable Function Violation: Unimplemented functions should be marked as unavailable (unavailable_function)

However, adding @available(*, unavailable) to greet in Base like this

class Base {
    @available(*, unavailable)
    func greet() { fatalError("Subclasses must override greet()") }
}
class Derived: Base {
    override func greet() { print("Hello World") }
}
Derived().greet()

will result in a compile error:

main.swift:6:19 Cannot override 'greet' which has been marked unavailable

I'm wondering if it would make sense to make this rule stricter and avoid reporting such cases, also considering visibility:

• open: I don't think these should be reported because they are expected to be overridden
• private: these should be reported because we can't override them (matches current behavior)
• fileprivate, internal, public: for this we would need to know if a function is being overridden within the same file/module. I don't know if SwiftLint already has this information when processing the AST, but usually linters work on individual files, so there is probably not much we can figure out about internal and public functions. Overriding for fileprivate might be determined by only looking at the file, but I'm not sure if it's worth the overhead.

Start with the unavailable_function rule and the Swift AST information available when analyzing the main.swift example. Determine how overriding and visibility should affect diagnostics, including open, private, fileprivate, internal, and public methods. Done means the rule's behavior is specified and covered for the relevant override cases.