@IBInspectable and @GKInspectable both work via the Objective-C
runtime. SE-0160 made them imply @objc, but doing so made it an error
to define an @IBInspectable or @GKInspectable property with a type
that could not be expressed in Objective-C. The attribute is useless,
but this broke Swift 3 code.
So, downgrade the error to a warning in Swift 3 compatibility mode,
with a Fix-It to remove the useless attribute. It remains an error in
Swift 4.
Fixes rdar://problem/31408971.
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.
When the 'dynamic' modifier is explicitly written on a declaration, it
requires the Objective-C runtime. In Swift 3, this (directly) implies
'@objc'. In Swift 4, it requires that the '@objc' be written
explicitly. Hence, a Swift 3 -> Swift 4 migration will always retain
the @objc-ness of the entry point, so we don't need to treat it as
"inferred".
Overriding of members introduced in class extensions depends on the
presence of an Objective-C entrypoint. When we override such a
member---which used the deprecated @objc inference rule and occurs in
a class extension, where non-@objc methods currently cannot be
overridden---warn about the use of explicit @objc.
When in Swift 3 compatibility mode without
`-warn-swift3-objc-inference`, warn on the *uses* of declarations that
depend on the Objective-C runtime that became `@objc` due to the
deprecated inference rule. This far more directly captures important
uses of the deprecated Objective-C entrypoints. We diagnose:
* `#selector` expressions that refer to one of these `@objc` members
* `#keyPath` expressions that refer to one of these `@objc` members
* Dynamic lookup (i.e., member access via `AnyObject`) that refers to
one of these `@objc` members.
