Non-‘@objc’ ‘dynamic’ has been allowed since Swift 5, but there’s no
reason to tie it to the language mode (Swift >= 5).
Fixes rdar://problem/50348013.
Previously they were ignored by the checking of '@objc', but in the
refactoring to a request the attribute started getting marked as
invalid without a diagnostic.
rdar://problem/43401047
Rather than the nebulous “do not diagnose”, separate out the two reasons for a non-diagnosed @objc: it’s a member of an Objective-C-derived subclass or it’s an accessor for a property.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
Now that generic subclasses of @objc classes are supported, dust off
Doug Gregor's fix for <rdar://problem/20385288>. It is now an error
to override an @objc declaration with something that cannot be
represented as @objc.
For example, the override of foo() here will not compile unless
it is explicitly marked @nonobjc:
func foo(i: Int) {}
...
override func foo(i: Int?) {}
Note that I updated IRGen to delete some logic for figuring out when
to emit @objc metadata. We can now rely on Sema to correctly set
isObjC(), instead of checking overrides ourselves. This was wrong
anyway, now that we can have @nonobjc overrides of @objc methods,
and vice versa.
Swift SVN r29263
We currently complain about this type of thing:
class C<T> {
@objc func foo() -> [T]
}
However this is also not supported, but crashes in IRGen:
class C {
@objc func foo<T>() -> [T]
}
Also re-word a @nonobjc diagnostic and clean up some code for @objc and
@nonobjc.
Fixes <rdar://problem/19600602> and <rdar://problem/20886887>.
Swift SVN r29117
The following declaration kinds can be marked with this attribute:
- method
- property
- property accessor
- subscript
- constructor
Use cases include resolving circularity for bridging methods in an @objc
class, and allowing overloading methods and constructors in an @objc class
by signature by marking some of them @nonobjc.
It is an error to override an @objc method with a @nonobjc method. The
converse, where we override a @nonobjc method with a @objc method, is
explicitly supported.
It is also an error to put a @nonobjc attribute on a method which is
inferred as @objc due to being part of an @objc protocol conformance.
Fixes <rdar://problem/16763754>.
Swift SVN r28126
