When generating a stub fix-it for a protocol conformance or implementation extension, Swift will now evaluate whether the context allows the declaration of stored properties and, if so, will suggest one. It will also use the `let` keyword instead of `var` if the property has no setter.
Changes the diagnostics emitted when an `@objc @implementation` extension is missing some of the members required by the extension:
• We now emit one error on the extension, plus a note for each missing member.
• Where possible, we also emit a note with a fix-it adding stubs.
For example:
```
9 | @objc @implementation extension ObjCClass {
| |- error: extension for main class interface does not provide all required implementations
| |- note: missing instance method 'method(fromHeader3:)'
| |- note: missing instance method 'method(fromHeader4:)'
| |- note: missing property 'propertyFromHeader7'
| |- note: missing property 'propertyFromHeader8'
| |- note: missing property 'propertyFromHeader9'
| |- note: missing instance method 'extensionMethod(fromHeader2:)'
| `- note: add stubs for missing '@implementation' requirements
```
With a fix-it on the last note to insert the following after the open brace:
```
@objc(methodFromHeader3:)
open func method(fromHeader3 param: Int32) {
<#code#>
}
@objc(methodFromHeader4:)
open func method(fromHeader4 param: Int32) {
<#code#>
}
@objc(propertyFromHeader7)
open var propertyFromHeader7: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader8)
open var propertyFromHeader8: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader9)
open var propertyFromHeader9: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(extensionMethodFromHeader2:)
open func extensionMethod(fromHeader2 param: Int32) {
<#code#>
}
```
Fixes rdar://130038221.
Automatically detect when shouldMarkAsObjC() will behave differently based on the objcImpl early adopter flag and diagnose it. This works in either direction, although there isn’t anything yet that will emit diag:: objc_implementation_will_become_nonobjc.
NFC except for some minor changes to the wording of notes.
In #69257, we modified `ObjCReason` to carry a pointer to the @implementation attribute for the `MemberOfObjCImplementationExtension` kind. This made it mark the @implementation attribute as invalid, suppressing diagnostics from the ObjCImplementationChecker.
However, invalidating the attribute *also* causes it to be skipped by serialization. That isn’t a problem if the diagnostics are errors, since we’ll never emit the serialized module, but #74135 softened these diagnostics to warnings for early adopters.
The upshot was that if Swift emitted one of these warnings when it compiled a library, clients of that library would see the objcImpl extension as a normal extension instead. This would cause various kinds of mischief: ambiguous name lookups because implementations weren’t being excluded, overrides failing because an implementation was `public` instead of `open`, asserts and crashes in SILGen and IRGen because stored properties were found in seemingly normal extensions, etc.
Fix this by setting a separate bit on ObjCImplementationAttr, rather than the invalid bit, and modifying the implementation checker to manually suppress many diagnostics when that bit is set.
Fixes rdar://134730183.
…for extensions. This change also removes @implementation(CategoryName); you should attach the category name to the @objc attribute instead. And there are small changes to how much checking the compiler will do on an @objc @implementation after the decl checker has discovered a problem with it.
ObjCImplementationChecker::matchTypes() implicitly assumed that if it was comparing function types, it must be working on an AbstractFunctionDecl. This isn’t true for a property of block type, which could cause crashes when checking their parameter types. Fix this oversight.
Fixes rdar://122280735.
We eventually want to be able to implement functions imported as globals or members in Swift, but we’re not there yet. Add some basic tests to make sure we get reasonable diagnostics for them.
Extensions to lightweight generic classes are such a huge mess that we’re just removing these from the feature’s scope for now.
Fixes rdar://116066409.
Suppose a superclass declares an initializer unavailable and then a subclass wants to redeclare and use it. Formally, the subclass declaration overrides the superclass one; however, Swift will not actually require the subclass to use the `override` keyword. As currently implemented, this means that the requirement will be skipped as an override, but the candidate will be included as a member implementation. Result: a “candidate does not match any requirement” diagnostic.
Fix this by skipping requirements that are overrides *only* if the declaration they override is not unavailable.
Fixes rdar://109541045.
Because `required init`s do not have the `override` keyword, they are always treated as member implementations (if they pass other checks). However, these methods sometimes actually are overrides, and when they are, they should not be treated as member implementations. This results in required inits being treated as candidates when there won’t be a requirement for them to match.
Hack around this by separately checking for this situation and skipping the affected members.
Fixes rdar://112910098.
ClangImporter can import some methods as throwing that `@objc` cannot generate. For instance, an imported Objective-C method with an error out parameter in an unconventional position can still be imported as throwing no matter its selector, but `@objc` can only generate an error out parameter in an unconventional position if the matching selector part consists of the word `error` or (for the first part) ends with `Error`. Detect and diagnose these situations.
Note that the tests do not cover all of the new diagnostics because some of these conditions (like the `Void` parameter) cause selector mismatches and others (like the owned error parameter) are representable in the compiler but cannot currently be imported. I have chosen to add these diagnostics anyway in case there is a corner case that I haven’t discovered.
Fixes rdar://110100071.
The @objcImpl checker would accidentally dereference a null pointer when it tried to check if an async requirement could be satisfied by a non-async method. Fix that mistake.
Fixes rdar://111064481.
@objcImpl extensions aren’t allowed to declare new conformances; instead, they should either be declared in the header or in an ordinary extensions. (If they were permitted, they’d be ignored.)
Fixes rdar://110669366.
• 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.
Sema now diagnoses @objcImpl implementations with:
• The wrong settability (i.e. a `let` used for a `readwrite` property)
• The wrong kind (i.e. a method used for a property)
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.
Without this change, an `@_objcImplementation` cannot override parent class methods, because the special access control behavior breaks the access control checks for overrides.
Stored properties are only allowed in the extension implementing the class's main interface, not its categories. This also means banning `@objc final`, which is unenforceable anyway when ObjC subclasses are allowed, and therefore allowing `@objc let` and `@objc static` properties to be overridden if they're declared in objcImplementations.
