[Sema] Add dedicated fix-it for NSObject.hashValue overrides

[lorentey]

(Note: I intend to submit this for inclusion in 5.0, too.)

NSObject.hashValue used to be declared @objc open by historical accident. Unfortunately, overrides of NSObject.hashValue never worked correctly.

Swift 4.2 deprecated such overrides (#18407), and the property has been corrected to @nonobjc public in Swift 5.0 (#20129).

Help migration of existing code by adding a dedicated error message for overrides of NSObject.hashValue, with a nice fix-it directing people to override NSObject.hash instead.

// smash.swift
import Foundation

class Foo: NSObject {
  override var hashValue: Int {
    return 42
  }
}

Before:

$ swiftc smash.swift
smash.swift:4:16: error: overriding non-open property outside of its defining module
  override var hashValue: Int {
               ^
smash.swift:4:16: error: overriding non-@objc declarations from extensions is not supported
  override var hashValue: Int {
               ^
ObjectiveC.NSObject:3:25: note: add '@objc' to make this declaration overridable
    @nonobjc public var hashValue: Int { get }
                        ^

After:

$ swiftc smash.swift
smash.swift:4:16: error: 'NSObject.hashValue' is not overridable; did you mean to override 'NSObject.hash'?
  override var hashValue: Int {
               ^~~~~~~~~
               hash

rdar://problem/45674813

[lorentey]

@swift-ci please test

[lorentey]

Unfortunately, NSObject.hashValue is still declared open in swift-corelibs-foundation, so this is a little more complicated than it should be. (The old deprecation warning remains for now, as we need to support both variants.) Fixing that is in progress (swiftlang/swift-corelibs-foundation#1820), but it won't necessarily land in the 5.0 timeframe.

[lorentey]

cc @airspeedswift @DougGregor @brentdax

[jrose-apple]

Arguably it's correct to warn even before the corelibs-foundation change, yeah?

[lorentey]

Yes! We've had this warning on all platforms since 4.2. But I see no reason to keep it once NSObject.hashValue becomes non-open everywhere; it would never trigger in practice.