Warn about cases where a storage declaration (property or subscript)
has an accessor with an explicit @objc, but for which the storage
declaration itself is only @objc due to deprecated @objc inference.
These are never part of an @objc protocol, so we shouldn't bother
looking for them and certainly shouldn't expect them to be there.
Fixes a crash introduced in 1f2121377.
rdar://problem/30101703
Most property accessors have selectors matching their protocols, but
not all. Don't force the user to write '@objc' explicitly on an
accessor, which isn't even possible for stored properties.
More groundwork for rdar://problem/28543037.
When we cannot infer an @objc name due to an ambiguity, provide a
specific error with Fix-Its for various courses of action (pick a
specific name, make it @nonobjc). Also, be sure to suppress redundant
diagnostics for Objective-C selector checking when checking protocol
conformances: a match-with-renaming will emit the appropriate '@objc'
when it's needed, so we don't need a follow-up diagnostic here.
Finishes rdar://problem/26518216.
When a particular method/initializer/property/subscript is used to
satisfied a requirement in an @objc protocol, infer both the presence
of @objc and the @objc name so that it matches the requirement. This
eliminates the need to explicitly specify @objc and @objc(foo:bar:) in
most cases. Note that we already did this for overrides, so it's a
generalization of that behavior.
Note that we keep this inference somewhat local, checking only those
protocols that the enclosing context conforms to, to limit
spooky-action-at-a-distance inference. It's possible that we could
lift this restriction later.
Fixes rdar://problem/24049773.
When a non-@objc witness matches an @objc requirement except for
@objc-ness, treat it the same way whether it's an optional requirement
or not, except that it's a warning for the optional case. Should
finish off rdar://problem/25159872.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
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.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
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.
Previously, we attempted to infer @objc-ness based on conformance, but
doing so is fraught with ordering dependencies, and just doesn't work
in the general case. Among other crimes, this allowed us to
retroactively mark a non-@objc method from an imported module as
@objc... even though nobody would ever then emit the @objc entry
points for it.
Fixes the rest of rdar://problem/18383574.
Swift SVN r24831
An optional @objc requirement within a protocol can be left
unsatisfied in a well-formed program. However, there may still be a
conflict within the Objective-C runtime if the conforming class
defines a method with the corresponding Objective-C selector(s) for
that requirement, which means that the Swift and Objective-C semantics
will differ. Diagnose such issues.
More steps along the road to fixing rdar://problem/18383574.
Diagnose conflicts between unsatisfied, optional @objc requirements and
Swift SVN r24830
When we match a witness to a requirement in a protocol, we do so based
on the Swift name (which is correct). When the requirement is @objc
(because it is in an @objc protocol), also check that the Objective-C
selectors of the witness match those of the requirement.
Fixes the majority of rdar://problem/18383574.
Swift SVN r24829
