Type and property renaming

[ctxppc]

Silica should try to re-associate localised string entries after a LocalisableString type (or a property thereof) has been renamed since the last run of the Silica tool. Currently any renames result in the previous localised string entries becoming disassociated (and marked with a “Unused” comment) and new (empty) localised string entries being created, requiring manual re-association.

Since Silica doesn’t retain source information and doesn’t participate in refactoring tools, it cannot know what renames have occurred. It can however heuristically determine what renames might have occurred by introspecting the unused localised string entries and trying to match them to newly created localised string entries. Silica should work pessimistically and only re-associate a localised string entry when either a single type, a single case, or a single property (across the whole codebase) has been renamed between runs of the Silica tool. In addition, it should emit a warning (once) notifying the developer that such re-association has been performed.

As an example, given the following code:

enum CarColour {
    case red
    case blue
}

Silica generates the following entries:

"CarColour.red" = "red";
"CarColour.blue" = "blue";

After renaming the type to CarColor (but no other LocalisableString type or a case or property thereof), Silica should generate the following entries:

"CarColor.red" = "red";
"CarColor.blue" = "blue";

and emit “warning: Silica re-associated string entries from type ‘CarColour’ to ‘CarColor’”.