Rule request: Empty overrides

New Issue Checklist

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

New rule request

It happens that we overwrite a function from the superclass, and actually do not add any functionality apart from calling super. This becomes frustrating at the code review for peer engineers.

What would trigger?

class Foo {
    let value: Int
    init() {
       self.value = 0
   }
}

class Bar: Foo {
   override init() {
       super.init()
   }
}

class Foo {
    func start() {
        print(type(of: self))
    }
}

class Bar: Foo {
    override func start() {
        super.start()
    }
}

class Foo {
    var computedValue: Int {
        return 0
    }
}

class Bar: Foo {
    override var computedValue: Int {
        return super.computedValue
    }
}

class Foo {
    var computedValue: Int {
        return 0
    }
}

class Bar: Foo {
    override var computedValue: Int {
        // Lets overwrite this computedValue property and don't do anything else
        return super.computedValue
    }
}

What would not trigger?

class Foo {
    init() { }
}

class Bar: Foo {
    let value: Int

    override init() {
        self.value = 1
    }
}

class Foo {
    let value: Int
    init() {
       self.value = 0
   }
}

class Bar: Foo {
   let otherValue: Int
   
   override init() {
       self.otherValue = 1
       super.init()
   }
}

class Foo {
    func start() {
        print(type(of: self))
    }
}

class Bar: Foo {
 
    var isStarted = false

    override func start() {
        super.start()
        isStarted = true       
    }
}

class Foo {
    var computedValue: Int {
        return 0
    }
}

class Bar: Foo {
    override var computedValue: Int {
        return 1
    }
}

Should it be configurable?
It could be configurable to treat it as an error or a warning.

Opt-in or default?
I would propose to make it default, since an empty override does not add any functionality.

Start by reviewing SwiftLint's existing rule implementations and tests for how Swift override declarations and superclass calls are analyzed. Use the triggering and non-triggering Swift examples in the issue to define coverage, and consider how the proposed warning-versus-error configuration should behave. Done means the new rule detects only overrides that add no functionality and has tests for each listed case.