• Allow `required init`s in @objcImpl extensions of a class’s main body
• Validate that the presence or absence of a `required` modifier matches the imported header declaration.
Fixes rdar://110016760.
Check the types of @objcImpl candidates against their requirements and diagnose *most* mismatches.
Unlike typical type matching rules, @objcImpl allows an implementation’s parameter *and* result types to be an IUO when the requirement isn’t. This runs against the normal covariance rules in the case of the result type. It’s meant to allow an implementation to handle nils passed to it and return nils even if the declaration formally claims nils are not permitted; this is occasionally necessary to reimplement Objective-C APIs without breaking ABI compatibility.
Fixes rdar://102063730.
Create a checker for @_objcImplementation member implementations that considers all of a class’s interface and implementation decls at once. This allows us to handle several things better:
• Unimplemented requirements are now diagnosed
• Header members that can match several implementations, or implementations that could match several header members, are now diagnosed
• Tailored diagnostic when the implementation's Swift name matches the header's selector instead of its Swift name
• Recommends inserting `@objc(<selector>)` when a Swift name matches but the implicit ObjC name doesn't
• An `@objc(<selector>)` on one implementation can eliminate its requirement from being considered for other implementations, resolving ambiguities
This does unfortunately regress the diagnostics when a requirement is implemented in the wrong extension. Some sort of whole-module checking would be needed to address this problem.
Create a checker for @_objcImplementation member implementations that considers all of a class’s interface and implementation decls at once. This allows us to handle several things better:
• Unimplemented requirements are now diagnosed
• Header members that can match several implementations, or implementations that could match several header members, are now diagnosed
• Tailored diagnostic when the implementation's Swift name matches the header's selector instead of its Swift name
• Recommends inserting `@objc(<selector>)` when a Swift name matches but the implicit ObjC name doesn't
• An `@objc(<selector>)` on one implementation can eliminate its requirement from being considered for other implementations, resolving ambiguities
This does unfortunately regress the diagnostics when a requirement is implemented in the wrong extension. Some sort of whole-module checking would be needed to address this problem.
Previously, Swift would reject an `override public init(…)` in an `@_objcImplementation` because ClangImporter would have already synthesized inherited initializers that conflicted with the overrides. Ignore these spurious conflicts, and also move a check out of IsObjCRequest and into the conflict-handling code.
Additional work towards rdar://70730077.
