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.
Add a special case for `TypeExpr` due to i.e. context specialization,
in such cases there is nothing for the solver to "open" so we need
to form opened type map manually.
Resolves: rdar://111059036
@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)
Now that `InferredGenericSignatureRequest` creates
`StructuralRequirement`s from of the generic signature with valid source
locations, additional redundancy warnings are produced. Update tests
with the new warnings.
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
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.
• `@objc` is now inferred on non-`final` members of @objcImplementation extensions
• Diagnostics now suggest adding `private` to ObjC helper members, not `@objc`, in line with currently proposed behavior
• Better diagnostic for members implemented in the wrong extension
Part of rdar://103150189.
Specifically:
1. Fix the error message so that when we say you can't have a deinit that a
deinit can be on a noncopyable type along side a class or an actor.
2. Even though we already error on @objc enums and say they cannot be
noncopyable, we did not emit an error on the deinit saying that @objc enums
cannot have a deinit. I put in a nice to have error just to make it even
clearer.
rdar://105855978
rdar://106566054
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.
• `@objc` is now inferred on non-`final` members of @objcImplementation extensions
• Diagnostics now suggest adding `private` to ObjC helper members, not `@objc`, in line with currently proposed behavior
• Better diagnostic for members implemented in the wrong extension
Part of rdar://103150189.
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.
Treating this as forbidden was incorrect; an `@objc final` method is simply one that isn’t a member implementation but does have an ObjC entry point.
Formalize and centralize the definition of what a member implementation is, tweak it so that it’s basically “non-final and internal or greater”, and permit `@objc final`. Also remove the inference of `final` on `let`s in @_objcImpl extensions.
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.
Calling computeExtendedNominal() won't catch the case where the
extended type did not exist at extension binding time but then
appeared later, like an inferred associated type witness for
example.
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
A scoped-down version of #39307. Implement extension of bound generic types. The important bit here is in TypeCheckGeneric where we now use the underlying type of a typealias and its associated nominal type decl when we're generating substitutions for the extended type.
Put this behind a new experimental flag
-enable-experimental-bound-generic-extensions
Resolves SR-4875
Resolves rdar://17434633
* Don't crash when missing a type in a Diagnostic message.
Print an empty string for the missing type.
Resolves SR-12460
* Added new diagnostic message, eg. "operator '==' declared in extension must be 'static'"
