migrator: handle AppKit protocol migrations. rdar://42480588

[nkcsgexi]

rdar://42480588

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@nathawes could you please review this patch for swift-4.2-branch?

[nathawes]

Is this based purely on the function name at the moment?

If it is, it seems like this migration would cause errors if

1. I have my own class with a similarly named, but unrelated method, e.g. 'changeColor(_ color: Color)', that I override in subclass (the subclass' override should be left alone)
2. I have a subclass of NSObject and a subclass of that subclass that both override one of these methods (the sub-sub-class' method should still override).

Some of the names seem specific enough that the above wouldn't happen too often in practice, but I could imagine it happening for a few of them.

[nkcsgexi]

yeah, I think it is safer to use USR for identifying these overriding function. Will change!

[nathawes]

Shouldn't this check if the thing it's referencing is one of the targeted methods? E.g. I might be calling some unrelated method on NSObject that I also happen to override and I want to call the super class' version rather than my own.

[nkcsgexi]

Good point! I'll add this check for these function invocation.

[nathawes]

This doesn't seem like the right place for this one. E.g. I might also use super.changeColor() in methods other than my override of changeColor() if I don't want to use my override.

[nkcsgexi]

@nathawes I've addressed your comments above. Mind taking another look?

[nathawes]

LGTM Xi! Thanks for updating it.

[nkcsgexi]

@swift-ci please smoke test

[nkcsgexi]

@swift-ci please smoke test