Weaken the minimum deployment target error to a warning for objcImpl adopters using the legacy `@_objcImplementation` syntax until we determine exactly how far back it can be safely used.
Fixes rdar://129225596.
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.
This now specifies a category name that’s used in TBDGen, IRGen, and PrintAsClang. There are also now category name conflict diagnostics; these subsume some @implementation diagnostics.
(It turns out there was already a check for @objc(CustomName) to make sure it wasn’t a selector!)
This protocol appears in the stdlib as scaffolding for the
`NonescapableTypes` feature, which is still experimental and not gone
through evolution as an approved addition to the stdlib.
Rather than delete it from the stdlib, because it needs to still remain
to support that feature work, gate references to it behind a feature
flag.
Additionally, prevent documentation from seeing this declaration.
rdar://126705184
• ObjCImplementation controls @implementation on extensions
• CImplementation controls @implementation and @_objcImplementation on cdecl functions
Why the difference between them? Because `@_objcImplementation extension` has already been adopted pretty widely, while `@_objcImplementation @_cdecl` is very new.
The recent change to make objcImpl examine class extensions has collided with a workaround some projects were employing where they declared class extension member implementations `private`. Now that we’re checking class extensions in objcImpl extensions, this workaround is creating selector conflict errors in some circumstances. Soften selector conflict errors in objcImpl extensions to warnings so the affected projects continue to build.
Fixes rdar://123347290.
Member implementations are never directly visible to clients of a module, even if they are formally public, but TypeCheckAvailability did not know this. As a result, it would incorrectly diagnose member implementations in an objcImpl extension as violating @_implementationOnly import rules or other, similar access checks. This commit excludes them from being considered as exported declarations.
Fixes rdar://121229058.
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.
There's no good reason to permit them. Conformances like Copyable and
Sendable are pervasive, so it's as though we are permitting extensions
of `Any`. Until there's a good argument in favor of such extensions,
remove the capability now.
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.
This commit diagnoses cdecl implementations with no matching imported declaration, and also runs them through the ObjCImplementationChecker. Actually testing that the ObjCImplementationChecker diagnoses various failure conditions correctly will be added in a subsequent commit.
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.
Required and designated inits have to be overridable—the former so that uses of the initializer on `any T.Type` will call the subclass initializer, the latter so that inherited convenience inits will call the subclass initializer. However, Swift-only members use vtables to dispatch to subclasses, and @objcImpl classes don’t have vtables, so their Swift-only inits cannot be made overridable. Upshot: Swift-only inits on @objcImpl classes must be `convenience`, not `required` or designated.
Enforce this rule in the ObjCImplementationChecker.
Fixes rdar://109121293.
Nothing in an `@_objcImplementation` block—including Swift-only declarations—should ever require a vtable entry. Diagnose any such members.
The diagnostic emitted here is intended to be a fallback that will be used when a vtable entry is needed but we don’t know the specific reason. A future commit will add a more specific diagnostic for Swift-only non-convenience inits.
Besides improving diagnostics, this also allows us to track whether there were any @objc failures using the invalid bit on the @_objcImplementation attribute.
Initializers can’t be made final, but they *can* be made @nonobjc. (This isn’t always enough to ensure they’re actually valid, but I’ll get to that in a follow-up commit.)
The fix-it suggesting that an unmatched `@objc`-able member can be turned `private` always suggested adding a new modifier, even if one already existed. Make it suggest replacing the existing one instead.
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.
Temporarily cherry-pick Swift 5.9’s behavior of turning @objcImplementation errors into warnings to 5.10 until we fix the last few bugs in these diagnostics.
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.
