Potentially unintuitive behavior when `rules` dictionary is incomplete in configuration

[allevato]

SwiftSyntax uses a configuration that only lists a subset of the rules, with the intention of only adjusting the ones that they want to differ from the defaults (link).

Unfortunately, that's not what's actually implemented. When the configuration is decoded from JSON, it loads the rules dictionary as-is. Only if the rules key is not present at all does it fall back to the default rule dictionary. If rules is present but incomplete, it's used verbatim, and rules not present in the dictionary aren't enabled even if they would be enabled by default in the default configuration.

This is the documented behavior on the rules field of Configuration:

  /// The dictionary containing the rule names that we wish to run on. A rule is not used if it is
  /// marked as `false`, or if it is missing from the dictionary.

But that may not be what the user intended by removing rules from the dictionary. It also means that once someone has a configuration they're using, no new rules added in later versions of swift-format will be enabled unless they add them manually, even if they would have been enabled by the default configuration.

If we think the current behavior is wrong, we can fix it by having the rule code fall back to the isOptIn property instead of just false for rules that it doesn't recognize. This does have the potential, however, of being a surprising change in behavior for people who are using configurations today with partial rule sets, so we need to decide if we're ok with that change in an upcoming release.

Another option would be to bump the configuration version number and have that determine the behavior.

[ahoppen]

Synced to Apple’s issue tracker as rdar://137275279

[andre-richter]

Adding the perspective of a user who came from clang-format:

I was indeed very surprised by this behavior and actually tried to debug this to understand what I was doing wrong when some default rules seemingly weren't enforced. I intuitively was populating the rules dictionary only with items that I wanted to differ from the standard configuration.

Having "not-listed-means-default-value" behavior would also help to cut down on the size of .swift-format files, because I would expect that users on average only want to diverge only from a handful of the defaults.
Additionally, it would nudge the formatting style in the broader swift-format-users community to become a little more uniform, because it makes swift-format a little more opinionated, which I would consider a positive outcome.

Another option would be to bump the configuration version number and have that determine the behavior.

Seems like a reasonable approach 👍