@swift-ci create

Given source compatibility constraints, the best we can do is warn. This is sorta a StarterBug for the Decl Checker. Ping me here for more details.

Comment by Faiçal (JIRA)

Hi @CodaFi! Happy to take this on. Would be grateful for any pointer you could give me to get started 🙂.

faical (JIRA User) There's a big condition soup in OverrideMatcher::checkOverride that needs to be updated. Detecting whether a decl has been ClangImport'ed into Swift is simple (just ask Decl::hasClangNode). So the logic is roughly: If the type matches, and the decl context for the declaration is an extension, and the extended decl context is ClangImport'ed, then warn. You'll need to do this for subscripts, variables, and functions - you can probably catch-all by just doing it for ValueDecls and using the descriptive decl kind to render a nice diagnostic.

Finally, you'll need some kind of syntax to silence this warning. There's precedent in allowing bogus overrides as long as the user spells them with parens around the type, so we can probably just suggest that in a note carrying a fixit. That is, this ought to warn:

extension UITabBarController {
  open override var shouldAutorotate: Bool { // warning: extension declares override of Objective-C property 'shouldAutorotate'; this will cause unstable runtime behavior
                                                                           // note: add parentheses to silence this warning
    return true
  }
}

This shouldn't

extension UITabBarController {
  open override var shouldAutorotate: (Bool) {
    return true
  }
}

@DevAndArtist If you'll forgive a little language-lawyering, technically this behavior is not undefined - the documentation is a little extreme here. Load-time ordering is consistent across runs of an application, and the runtime guarantees that somebody's category or class is going to win. The unstable bit is who that actually is at runtime.