Setting 'warning' in SeverityLevelsConfig should unset 'error'

[mgrebenets]

I am getting false positive error messages from swiftlint version 0.6.0.

Here's a picture that describes it the best.

.swiftlint.yml looks like this:

disabled_rules: # Rule identifiers to exclude from running
  - nesting
  - todo
excluded: # Paths to ignore during linting. Overridden by `included`.
  - Carthage
  - Pods
file_length: 600
line_length: 250
type_body_length: 500
function_body_length: 200
variable_name_max_length:
  - 48 # warning
  - 64 # error

The error stays no matter what, even if I bump some values, for example, increasing type_body_length to 700:

[scottrhoyt]

I see what is going on here. TypeBodyLength has both warning and error levels. While you are successfully raising the warning level to 500, the error level is remaining the default of 350. An immediate workaround would be to specify this in your .swiftlint.yml:

type_body_length:
  warning: 400
  error: 700 # something higher than 400

@jpsim we should consider if we should allow warning levels to be set higher than error levels. I see validity in each approach.

[jpsim]

@scottrhoyt we could consider it a configuration error (e.g. throw ConfigurationError) to set a warning to be "less strict" than the error value (in this case, higher). Or maybe it'd be preferable to erase the error value when setting a warning value?

[scottrhoyt]

@jpsim I think I like the latter route better because the former requires that we expose the knowledge of rules with increasing warning/error thresholds (e.g. FileLengthRule) and those with decreasing thresholds (e.g minLength for TypeNameRule). It also has the value of making .swiftlint.yml more deterministic.

[jpsim]

Agreed. I've updated this issue title to better track that.

[robinkunde]

@scottrhoyt I came across the same problem today and prepared a pull request (#431) similar to the solution you agreed on before I found this issue.

[scottrhoyt]

Thanks for the contribution @robinkunde, the SwiftLint community appreciates it! Looking forward to checking it out.

[scottrhoyt]

@jpsim this is closed by #438, correct?

[jpsim]

Yup! Thanks for being ever vigilant!