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.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
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.
A previous change made it so that an objcImpl extension could declare a `final` or `static` member which overrode an `@objc` superclass method, or witnessed an `@objc` protocol requirement, without itself being `@objc`. Prevent that from happening by allowing processing of `final` members to continue to later codepaths, rather than returning early.
Fixes rdar://136113393.
Before the update to support the new syntax, the decl checker treated private and fileprivate members of objcImpl extensions as non-@objc by default. But SE-0436 specified that private and fileprivate members should be implicitly @objc unless opted out, so when support for the final syntax was added, this behavior was changed retroactively.
Unfortunately, we’ve found that some early adopters depended on the old behavior. Restore some logic deleted by #73309 for early adopter syntax *only*, with a warning telling the developer to put `final` or `@nonobjc` on the declaration if they want to preserve the behavior after updating it.
Also tweaks the ObjCImplementationChecker to ensure this logic will actually be run in time for it to suppress the “upgrade to @objc @implementation” warning, and corrects a couple of regressions arising from that change.
Fixes rdar://135747897.
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.
Before the change from @_objcImplementation to @objc @implementation, if a member was unrepresentable in ObjC, it would become implicitly `final`. After that change, this is now an error. We do want a diagnostic here, but we don’t want to break backwards compatibility for early adopters.
Soften the error to a warning when the old @objcImplementation syntax is used.
Fixes rdar://129247349.
…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.
