It's not obvious that we can check that hash/equality behavior
is entirely correct, since there are two very different behaviors
which depend on environmental factors that are not easy to test for.
But we can do a quick probe to see whether the current environment
seems to be offering the legacy or non-legacy behavior and then
carefully verify that everything else is consistent with our initial
probe.
This gives us confidence that at least we're not getting inconsistent
behavior.
For an Equatable type, we need a hash implementation that
is compatible with any possible definition of `==`.
Conservatively, that means `-hash` must return a constant.
For non-Equatable types, we know that `==` is identity based,
so we can get better hash behavior by using the object address.
Caveat: This means that non-Equatable types will do two
protocol conformance checks on every call to `hash`.
If a Swift type implements Equatable and/or Hashable and
we then pass that object into ObjC, we want ObjC
`isEqual:` and `hashValue` to use that. This allows
ObjC code to build ObjC collections of Swift objects.
* Support for Hashable struct/enum types was implemented in #4124
* Support for Equatable struct/enum types was implemented in #68720
* This implements support for Hashable and Equatable _class_ types
Caveats:
1. This does a lot of dynamic lookup work for each operation, so is
inherently rather slow. Unlike the struct/enum case, there is no convenient
place to cache the conformance information, so it's not clear that there is a
viable way to make it significantly faster.
2. This is a behavioral change to low-level support code. There is a
risk of breaking code that may be relying on the old behavior.
* cmake: Propagate SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT to overlay builds.
* runtime: Clear the correct bit in getROData()
* test/IRGen/objc_class_export.swift: Allow either is-Swift bit.
* test/stdlib/SwiftObjectNSObject.swift: Allow either name for SwiftObject.
The use of `__APPLE__` is unnecessary as the case is guarded by the
`SWIFT_DARWIN_ENABLE_STABLE_ABI_BIT` preprocessor guard which is implicitly
specific to that environment. Additionally, flip the condition around so that
the positive (which is the future) appears ahead of the negative case.
