Add a way to make format-capable rules lint but not format

[allevato]

For rules that can both do linting and perform complex tree transformations during formatting, users may prefer having the diagnostics when linting but not automatically perform the transformation during formatting. Right now, you can only achieve this with separate configurations. It might be nice to have the ability to tell certain rules "only lint, but don't format".

The easiest way to achieve this would be to change the rules dictionary from [String: Bool] to [String: SomeMoreComplexValue] that lets the user apply different settings to different rules.

If we do this, we'd need to customize the decoding logic to preserve the original behavior of Boolean values from older configurations.

However, this might also be an opportunity to allow other customizations. For example, it's been requested before (but I can't seem to find an issue) to allow customizing the severity levels of different rules. And we could take the top-level customization structs for the rules and nest them in the rules themselves. So maybe this is worth a holistic configuration version bump to tackle multiple cleanups at once.

[natikgadzhi]

This sounds interesting!

I think there's a spectrum (and somewhat of a slippery slope) of customizations that we could provide:

• We could provide "overrides" similar to eslint: https://eslint.org/docs/latest/use/configure/configuration-files#configuration-based-on-glob-patterns
• We could also make swift-format respect .swift-format-ignore file that includes paths to ignore

I think in some other languages where formatting is more valuable (ahem JavaScript), formatting and linters became very complex, and we probably don't want that for Swift.

How do you make decisions about flexibility vs complexity vs maintenance costs in swift-format? How should we go about it in this case?

[ahoppen]

Tracked in Apple’s issue tracker as rdar://126948389