Add ability to customize severity via config file

[bkolb]

In order to customize the severity of rules, I added
the possibility to do so via the configuration files.
If no severity is specified, we use the one pre-determined
by the Rule itself.

Example:

    {
        "ruleSeverity": {
            "AlwaysUseLowerCamelCase": "warning",
            "AmbiguousTrailingClosureOverload": "error",
        }
    }

Issue: #879

[allevato]

Thanks for the PR!

It looks like there's some noise in it from other merge commits (like the CMake and Package.swift files), can you rebase your changes on top of main and push that?

In general, I agree that we need a way to do this, but I don't think adding a separate dictionary for rule severity is the right answer here. The configuration file has already grown to be a bit of a mess as more and more settings have been added to it, and I'd like to revisit it holistically instead of continuing to graft more things on top of it. Overall, I think we need to remove the distinction between "rules" (in the swift-syntax visitor/rewriter sense) and the settings that affect the pretty-printer.

[bkolb]

Thanks for the quick feedback. I rebased on top of main.

I would agree that the config file can use some improvement. Generally, I don't think the separation between linting and formatting makes a lot of sense. There are linting rules that can/could provide rewrites as well (e.g the position of let in a case). This goes all the way up to the cli, where you can either specify -i or lint. To me this sounds like a significant change, likely leading to a v2 of the config file?

That being said, I think it is not bad to have a section in which you enable and configure the rules and a section that configure the severity.

[allevato]

I would agree that the config file can use some improvement. Generally, I don't think the separation between linting and formatting makes a lot of sense. There are linting rules that can/could provide rewrites as well (e.g the position of let in a case). This goes all the way up to the cli, where you can either specify -i or lint. To me this sounds like a significant change, likely leading to a v2 of the config file?

Yes, it would (and it would be the first one, since we've never done a breaking format change before).

That being said, I think it is not bad to have a section in which you enable and configure the rules and a section that configure the severity.

Since the configuration is user-facing, I want to be extremely cautious about introducing large new capabilities in a format that we don't think is ideal if we plan to change the format later, because that makes it more difficult for end-users to work with. We've been somewhat relaxed about simple boolean or integer values for the pretty printer, but this is a much bigger change and I don't want to create churn for users by getting them accustomed to one format and then changing it under them shortly after.

I might be able to take a look at redesigning the configuration in the coming weeks as other things slow down before the holidays.

[bkolb]

I changed my approach a little bit. This way, the configuration is still backward compatible.