backing-property-naming rule shouldn't be applied to fields that have the override modifier

[Ezard]

Expected Behavior

If a class overrides an abstract field that is not named according to standard conventions (e.g. __typename in code generated by GraphQL libraries such as Apollo), then the overridden field should not have a lint warning for its name, as the user has no control over this field name. Only the base field should have the lint error triggered for it (for the GraphQL example it would not be triggered, as the base field is generated code that Ktlint rightly ignores)

e.g.

// autogenerated code
interface SomeGraphQLType {
  val __typename: String
  // other, conventionally-named fields
}

// user code
object : SomeGraphQLType {
  override val __typename = "something" // <-- unfixable lint error
}

Current Behavior

A lint warning is raised for overridden fields which do not comply with standard naming conventions

Additional information

• Current version of ktlint: 1.3.1