[6.0][Concurrency] Implement a narrow carve out in the isolation override checking for NSObject.init().

[hborla]

• Explanation: [6.0][Concurrency] Don't ignore mismatching isolation for overrides of Clang-imported superclass methods. #74238 added new data-race safety diagnostics for overriding the isolation of a superclass method that's imported from Objective-C. This started diagnosing @MainActor-isolated types that override NSObject.init.

  Now, overriding NSObject.init() within a @MainActor-isolated type is difficult-to-impossible, especially if you need to call an initializer from an intermediate superclass that is also @MainActor-isolated. Standard opt-out tools like MainActor.assumeIsolated cannot be applied to things like stored property initialization and super.init(), making the issue extremely difficult to work around. This is a major usability regression for programs that interoperate with Objective-C and make heavy use of @MainActor-isolated types.

• Scope: Only impacts isolated overrides of NSObject.init().

• Issues: Swift 6 regression overriding initializers due to Swift Concurrency #75732, rdar://133349184

• Original PRs: [Concurrency] Implement a narrow carve out in the isolation override checking for NSObject.init(). #75748

• Risk: Low; the only effect is removing warnings in complete concurrency checking / errors in Swift 6 mode. This carve-out won't admit a runtime data-race safety hole, because dynamic isolation checks will be inserted in the @objc thunks under DynamicActorIsolation, and direct calls will enforce @MainActor as usual.

• Testing: Added new tests.

• Reviewers: TBD

[hborla]

@swift-ci please test

[andyj-at-aspin]

@hborla I fear this might also be occurring for other overridden methods of UIKit (maybe originally NS-) objects, such as viewWillAppear(), viewDidAppear() etc.

[hborla]

I fear this might also be occurring for other overridden methods of UIKit (maybe originally NS-) objects, such as viewWillAppear(), viewDidAppear() etc.

I can't reproduce a failure by overriding viewDidAppear in a @MainActor-isolated subclass of UIViewController, but if this is happening for methods that are marked as nonisolated or otherwise aren't annotated with @MainActor, then that is a deliberate result of my original change. Overriding superclass methods and changing isolation does risk a data-race, which is why I made the original change. If you believe the superclass method is incorrectly annotated, that is a framework problem that you should report via Apple Feedback Assistant.