Added lenient command line option

[mildm8nnered]

Addresses #5779

So I basically just copied #5226 (which I wrote).

If you have strict and lenient as true in the config file, a fatalError will be thrown, but either can be overridden by the --strict or --lenient command line options, and they will also override the opposite setting in the config file.

For example, if you have

lenient: true in your config file, but you specify --strict on the command line, you will get the strict behaviour, and your config file setting will be ignored.

I tested this manually - it was hard to do a unit test, because we fatalError instead of throwing an error right now.

As before, --strict and --lenient on the command line will also fatal error.

[SwiftLintBot]

	17 Messages
📖	Linting Aerial with this PR took 0.92s vs 0.94s on main (2% faster)
📖	Linting Alamofire with this PR took 1.25s vs 1.27s on main (1% faster)
📖	Linting Brave with this PR took 7.2s vs 7.19s on main (0% slower)
📖	Linting DuckDuckGo with this PR took 5.05s vs 5.09s on main (0% faster)
📖	Linting Firefox with this PR took 10.6s vs 10.57s on main (0% slower)
📖	Linting Kickstarter with this PR took 9.79s vs 9.83s on main (0% faster)
📖	Linting Moya with this PR took 0.53s vs 0.55s on main (3% faster)
📖	Linting NetNewsWire with this PR took 2.62s vs 2.64s on main (0% faster)
📖	Linting Nimble with this PR took 0.78s vs 0.79s on main (1% faster)
📖	Linting PocketCasts with this PR took 8.45s vs 8.53s on main (0% faster)
📖	Linting Quick with this PR took 0.46s vs 0.44s on main (4% slower)
📖	Linting Realm with this PR took 4.5s vs 4.47s on main (0% slower)
📖	Linting Sourcery with this PR took 2.31s vs 2.3s on main (0% slower)
📖	Linting Swift with this PR took 4.5s vs 4.48s on main (0% slower)
📖	Linting VLC with this PR took 1.27s vs 1.26s on main (0% slower)
📖	Linting Wire with this PR took 17.5s vs 17.46s on main (0% slower)
📖	Linting WordPress with this PR took 11.52s vs 11.5s on main (0% slower)

Generated by 🚫 Danger

[SimplyDanny]

The options turn more and more complex. It'd be really useful to have the combinations tested.

[mildm8nnered]

The options turn more and more complex. It'd be really useful to have the combinations tested.

Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.

[SimplyDanny]

The options turn more and more complex. It'd be really useful to have the combinations tested.

Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.

Not sure if it's clean to move applyLeniency into LintOrAnalyzeOptions. In there, it would naturally be internal and can thus be tested.

[mildm8nnered]

The options turn more and more complex. It'd be really useful to have the combinations tested.

Did you have anything particular in mind - it would be quite easy to expose the logic in applyLeniency for the interactions between command line and config options, or are you thinking of something more.

Not sure if it's clean to move applyLeniency into LintOrAnalyzeOptions. In there, it would naturally be internal and can thus be tested.

Something like this perhaps, which tests the logic, if not the actual violations mapping?

extension LintOrAnalyzeOptions {
    // config file settings can be overridden by either `--strict` or `--lenient` command line options
    func leniency(strict: Bool, lenient: Bool) -> (Bool , Bool) {
        let strict = (strict && !self.lenient) || self.strict
        let lenient = (lenient && !self.strict) || self.lenient
        return (strict, lenient)
    }
}