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